JPH0769920B2 - Document management processor - Google Patents

Description

DETAILED DESCRIPTION [Outline] In a client-server cooperation system or the like, a server has a database that manages a large number of document groups in a logical structure, and multimedia-compatible documents can be handled freely. With regard to the document management processing device thus configured, it becomes possible to systematically manage documents such as management of long documents, version number management, and shared management by freely operating logical relationships between documents or document elements. A tree consisting of a class, a plurality of subclasses under the class, and an entity corresponding to the document or the document element connected to the class or subclass, for the purpose of The logical structure management means for managing by the logical structure of the structure, the tree structure operating means for operating the tree structure, and the logical structure by the tree structure And a storage structure management means for managing a storage structure for mapping a physical structure indicating an actual physical storage location of a document or a document element.

[Industrial application field]

The present invention provides a document management process in which a server that has a database for managing a large number of documents in a logical structure in a collaborative system of a client and a server and the like can freely handle multimedia-compatible documents. Regarding the device.

Due to the diversification of application fields in computer systems, not only the management of files that store numerical character data and the management of files that store programs, but also various media types such as text documents, line drawings, graphs, and images There is a need for a document management system that can flexibly manage such documents.

[Conventional technology]

FIG. 9 shows an example of a conventional document management system, and FIG. 10 shows an example of a conventional document management file structure.

Early document management systems consisted of multiple files and multiple programs that handle each file with a different file organization for each media type (text document, line drawing, graph, image, etc.). Such disparate management for each media type has a completely different management form from the management of paper files in actual office work when a computer is not used, so it is not possible to smoothly transition to a computer system for office work. There was a problem.

Therefore, recently, as shown in FIG. 9, for example, a document management system in which a concept of a cabinet 61 capable of storing various kinds of media is introduced has been considered. Application program
The document processing 60 can execute the document processing while being aware of the data container called the cabinet 61 without being aware of the physical structure of the medium in which the actual data is stored.

The external view is as follows:

The cabinet 61 is based on the concept of an office cabinet.
It was realized on a computer, and this container (storage) is
Further, the drawers 62a and 62b and the folders 63a to 63c are hierarchized. The data stored in this container is called an object 65.

The cabinet 61 can also be called a kind of multimedia storage file because it can store various types of media constituting a document and conventional program resources. It can be considered that the container composed of the three layers of the cabinet, drawer, and folder corresponds to the directory that manages the number of other containers and objects stored under it. There is a concept of size in a container.

The object 65 is composed of medium-independent management information 66 used for managing and searching entity data, and media data 67 that is an entity that depends on the medium.
Both the management information 66 and the media data 67 can be carried between the host processor and the workstation (WS) by standardization.

The operations on the cabinet 61 are roughly classified into search, container operation, and object 65 unit operation. For the search, search the list of containers (Cabinet list →
It is possible to search by the management information 66 of the object 65 in the container (drawer list → folder list → object list). The operations of the container and the object 65 are registration, extraction, deletion, change of management information, copying, moving, saving and restoring.

The internal view that realizes the cabinet 61 is as follows.

The medium itself that actually configures the object 65 is called non-numeric character data, and it is regarded as a block of binary data, and management that does not depend on its structure is performed. The physical resource that stores this non-numeric character data is called the image storage file 69, and is a magnetic disk device 70 or optical disk device 71.
Assign this file to a medium such as. Unlike the general data management, the access method to the image storage file 69 does not have the concept of a record and allows input / output with an arbitrary data length.

In addition, a conventional program source, program data, and the like can be incorporated as a general file 72 in the container. It is a container unit and can be assigned to any file. Further, the container information and the management information 66 of the object 65 are stored in the management file 68 assigned to each cabinet 61.

The structure of the management data in the management file 68 is shown in Fig. 10 (a).
As shown in.

Cabinet attribute file 80, which has the attributes of each of the cabinets, drawers, and folders of containers and objects, and the relational information for the subordinate containers,
There are attribute files of a drawer attribute file 81, a folder attribute file 82, and a document attribute file 83.

For example, as shown in Fig. 10 (b), the document body file 84
Is assigned according to the cabinet name and password stored in the record in the cabinet attribute file 80.
Done.

The document bodies 85-1 to 85-n are associated with each other by the image identifier IID of the attribute information record in the document attribute file 83.

[Problems to be Solved by the Invention]

Although it has become possible to store and manage multimedia by using document management with a hierarchical container that introduces the concept of cabinets, drawers, and folders, the conventional method still has the following problems.

The application program depends on the container structure, and it is necessary to change the program due to structural changes due to capacity expansion and container reorganization.

Since the object management unit is one document, a large document cannot be updated simultaneously by multiple people.

Since the cabinet container has three layers, further detailed classification cannot be performed.

Document version management and documents cannot be related dynamically.

The present invention can solve the above-mentioned problems, freely manipulate logical relationships between documents or document elements, and systematically manage documents such as management of long documents, version number management, and shared management. The purpose is to do so.

[Means for Solving the Problems]

 FIG. 1 is an explanatory view of the principle of the present invention.

In FIG. 1, 10 is a data processing device having a CPU and a memory, 11 is a tree structure operating means for operating a tree structure for managing documents or document elements, 12 is a logical structure managing means, and 13 is a storage structure. Management means, 14 is a cabinet, 15a, 1
5b is a drawer, 16 is a physical structure management means, 17 is a magnetic disk device, and 18 is an optical disk device.

In the present invention, in order to strengthen the independence between the document data and the application program and improve the productivity of the application program, the approach from the document file to the document database is taken.
Then, as shown in FIG. 1, a logical structure is provided as a user view, and a document database having three hierarchical layers of a storage structure and a physical structure manages multimedia-compatible documents or document elements.

The logical structure management means 12 is a tree-structured logic composed of a class C1, a plurality of subclasses S1 to S10 under the class, and entities E1 to E7 corresponding to documents or document elements connected to the class or subclasses. A structure expresses and stores a logical relationship between documents or document elements.

The entire class is associated with a structured document group and a structured long document, and the class itself is a representative of it. A subclass is a structured class, and can form multiple layers. An entity is basically an entity of data and corresponds to one whole document or one element of the document. In some cases, the entity may also indicate the actual location information.

The storage structure management means 13 is introduced to prevent the logical structure from being directly affected by the physical structure, and maps the logical structure to the physical structure.
For this, for example, the configuration of the cabinet 14 that has been realized conventionally is used. Which cabinet 14 the logical structure class is assigned to is determined in the storage structure definition.
This allocates containers by media type or subclass.

The physical structure management means 16 maps the container of the cabinet 14 to a physical file provided in the magnetic disk device 17 or the optical disk device 18 by using the function realized conventionally. In this definition, the physical file is defined in consideration of the characteristics of the container such as the access method, space amount, access frequency, and storage cost for the container.

The tree structure manipulating means 11 is a processing means for carrying out operations such as creating, updating and deleting the tree structure managed by the logical structure managing means 12 in units of classes or subclasses.

In the example of FIG. 1, the document group of class C1 is associated with the cabinet 14 having the name CAB1, and in the cabinet 14, the drawer 15a having the name DTEXT for the text document and the image document And a drawer 15b whose name is DIMAGE are provided, and the entities E1 to E are provided in the drawer 15a.
4, Entities E5 to E7 are housed in the drawer 15b.

The mapping between the storage structure related to the container such as the cabinet 14 and the physical structure is the same as the management in the conventional document management system.

[Action]

The management of document data by a hierarchical container based on the concept of cabinets, drawers, and folders can be considered as an improvement and development of the conventional concept of directories in general file management. In the present invention, a logical structure that does not depend on this file structure is
By constructing an existing cabinet by adding it on, the logical relationship between documents or document elements can be expressed in a tree structure.

With this tree structure representation, the following can be realized.

Numeric and character items can be set for search in the class, subclass and entity. At this time, the items of the lower layer can inherit the definition items of the upper layer.

An entity can be shared by multiple classes and subclasses.

Classes, subclasses, and entities can be simultaneously accessed by multiple people, and at this time, exclusive control can be performed for each unit.

You can dynamically relate entities to each other and create a new subclass.

A class for version management can be prepared as a system class, and the entity targeted for version management can be managed in this class.

〔Example〕

2 is an example of a logical structure of a document database according to an embodiment of the present invention, FIG. 3 is an example of a tree-structured management table according to an embodiment of the present invention, and FIG. 4 is an embodiment of the present invention. An example of a dynamic link management table, FIG. 5 is an example of a version number management table according to one embodiment of the present invention, FIG. 6 is an example of a shared management table according to one embodiment of the present invention, and FIG. Example of data structure for managing storage structure in one embodiment, eighth
The figure shows the system configuration of an embodiment of the present invention.

The logical structure of the document database according to the present invention is managed by a tree structure as shown in FIG. 2, for example. In FIG. 2, ● indicates a system class, which is defined by the system, ○ indicates a class or subclass, which is defined by the user, and □ indicates an entity, which is the whole document or 1 of the document. Represents what corresponds to an element. An entity is basically an entity of data, and may also show the location information of the entity.

Classes, subclasses and entities are each identified by name. Class names are unique in the system, and subclass names and entity names are unique within the class. With this, the subclass name is "class name.subclass name",
The entity name can be easily specified as "class name.entity name".

As shown in FIG. 2A, the entities can be grouped under a certain class and the documents can be related to each other.

AA entities can be accessed by either X.X1.AA or Y.Y1.AA, which is a shared document.

Further, as shown in (b), it is possible to manage a structured long document in which the entire class Y is viewed as one document. (C) is an example of managing a large number of systematic document groups based on class Z.

(D) shows an example in which version number management is performed under the system class W, and the first version (H.1) and the second version (H.2) exist for the document H. . The same applies to document I.

In the case of this embodiment, the logical structure shown in FIG. 2 is realized by using a relational database inside the system. And the operation of the logical structure uses the SQL language.

FIG. 3 shows an example of a parts expansion type table by a relational database that manages the tree structure of a class. The example shown in FIG. 3 is a structural example of a table for the subclass Z2 of the class Z shown in FIG.

This parts expansion type table consists of items fixedly prepared by the system and items specified by the user. The system fixed items have the following meanings.

-"Distinguished Name" indicates a class, subclass, or entity, and is a system-generated unique name.

-"Affiliation name" is the identifier to which the subclass or entity belongs. In order to speed up the process of searching all subclass names and entity names under a certain subclass, there may be multiple belonging names.

-For "type", value 1 is class, value 2 is subclass, value 3
Represents an entity.

-"Storage location" indicates the storage location of each entity by the container name.

-"Logical name" is a name specified by the user. The subclass name and entity name are unique within the class.

Items 1 to n designated by the user are fields in which the user can freely set attributes and the like, and can be used for searching by setting keywords.

Exclusive control of a class, subclass or entity is
This is done by issuing an exclusive request for the "identification name". In this case, exclusion performance can be improved by excluding only the highest layer that represents the target set.

FIG. 4 shows an example of a dynamic link management table for dynamically linking documents of class X in the tree structure shown in FIG. The structure of this parts expansion type table is
This is similar to the example of FIG.

The original document of the related document is always one, and in this example, the documents B, C, E, and F are related documents.

The system class W prepared for version number management shown in FIG. 2 represents a version number management table as shown in FIG.

Items that are fixedly managed by the system include addition of "version number" and "derivative name" in addition to the items in the parts expansion type table shown in FIG.

-"Version number" is the version number of the entity (document) whose version is managed.

-"Derivation name" indicates the entity (document) of the derivation source of the version concerned by an identification name.

-A value of 4 for "type" means an entity (document) whose version is managed.

Shared documents are managed by a shared management table as shown in FIG.

When sharing the same document between multiple subclasses, the entity is retained without duplication and exclusive control is performed when accessing the document. The document AA shown in FIG. 2 is represented by the tree-structured management table shown in FIG. A value of 5 for "type" means that the document is shared. In this case, a plurality of classes or subclasses to which the document belongs are managed by the parts expansion type table shown in FIG.

The "identification name" shown in FIG. 6B is the identification name of the shared document. The “affiliation name” represents the identification name of the class or subclass to which the shared document belongs.

The storage structure in the present invention is introduced so that the logical structure is not directly influenced by the physical structure.
For this, the conventional cabinet configuration is used as is. The type of cabinet to which the logical structure class is assigned is defined in the storage structure definition. Here, containers are assigned by media type or subclass unit.

An example of defining the storage structure by media type is described below.

Assuming that text and image data are mixed in class Z, two drawers, DTEXT for text documents and DIMAGE for image documents, are used as containers in cabinet CAB1.
It is supposed to be prepared individually. Depending on the type of media stored in the cabinet CAB1, if it is text, it is stored in the container CAB1.DTEXT, if it is image data, it is the container
Store in CAB1.DIMAGE.

When the class and the container are associated with each other by using the media type as a key, it can be realized by the data structure as shown in FIG.

On the other hand, when the subclass is directly associated with the container, it can be realized by the data structure as shown in FIG. Here, each field has the following meanings.

-"Class identifier" is an identifier in the tree-structured management table. With this identifier, the logical structure can be associated with the storage structure.

-"Container name" is the name of the cabinet container.

-The "number of objects" is the size of the container indicated by the "container name" and is represented by the number of objects in the cabinet.

-"Object type" is the type of media stored in the container indicated by "container name". Shown by the object type stored in the cabinet.

-"Media type" indicates the media characteristics assigned to the container indicated by the "container name".

-The “storage period” is set in three stages: temporary, short-term, and long-term.

In the management of physical structure, a physical file suitable for the characteristics of the media is defined in the container as in the conventional technology, so that a file dedicated to non-numeric data, an optical disk dedicated to image data, a general file, etc. To be able to select.

The overall configuration of the system in which the above document database operates is as shown in FIG. 8, for example.

In FIG. 8, 30 is a workstation (WS), 31 is an application program for document processing, 32 is a client interface, 40 is a host processor, 41 is a monitor (OS), and 42 is a document management function that provides a document management function. A server, 43 is an SQL interface, 44 is a relational database management subsystem, 45 is a cabinet management interface, 46 is a cabinet management unit, 47 is a text search interface, 48 is a text search unit, 50 is a document database according to the present invention, 51
Is a structure management file, 52 is a container such as a cabinet, and 53 is a search file in which word information for search is stored.

An application program 31 that creates, edits, and prints a document runs on the workstation 30. The client interface 32 provides the application program 31 with an access interface () of the document database 50.

When the client requests access to the document database 50, the host processing device 50 causes the document management server 42 to access the document database 50 and responds with the result. This is called the request and response protocol ().

A structure management file 51 for realizing the logical structure of the document database on the host processor 40 side in order to develop the document management system up to now into a document database system.
And a search file 53 for realizing text search is prepared.
The structure management file 51 stores a parts expansion type table for managing the logical structure and the storage structure as described with reference to FIGS. 3 to 7.

The document management server 42 uses an SQL interface 43, a cabinet management interface 45, and a text search interface 47 as an access method for the document database 50. The text search interface 47, the text search unit 48, and the search file 53 may be omitted.

In particular, the document management server 42 creates, updates, deletes, in units of class or subclass, management information about the logical structure of the tree structure stored in the structure management file 51.
Has operation processing functions such as copying, moving, separating, and combining. Since the details of this process can be easily realized by the table operation function in the well-known SQL language, further description will be omitted.

In the case of hierarchical search, for example, the following processing is performed. It is assumed that the next hierarchical list of the subclass Z2 of the class Z of the tree structure shown in FIG. 2 is obtained. The following, and correspond to the interfaces of to shown in FIG.

Description of application program The following search function is an interface prepared by the client.

ret = search (& result, "Z.Z2", "NEXT", "CREATEDATE> = 19890801") ret: Return code of processing & result: Return area for list results "Z.Z2": Specify hierarchical name "NEXT": Hierarchical search instructions “CREATEDATE> = 19890801”: Instructions for searching by management information (created on or after 01/08/1989).

 Request protocol The data stream on the line is as follows.

Expand to SQL statement and search the parts expansion type table.

 Response protocol The data stream on the line is as follows.

It is a sequence of return code, set name, number of searches, and hierarchy list information.

The return code 0 is returned to the application program ret, and the search result of the set name, number of searches, and hierarchy list information is returned to & result.

〔The invention's effect〕

In the host / workstation cooperation system, the current practical level of document processing is mainly the use of individual office workers, and the number of documents to be handled is small and the commonality is often low. However, from now on, not only in the office,
It is expected that document processing will also be applied to research and development departments and design / manufacturing departments. Unlike the office field, which handles a small amount of documents, this field is thought to handle a large number of documents and a large number of documents in many cases. A long document is a logically grouped document created by a plurality of people jointly, such as a product manual. The long document is structured, and the operation in the minimum unit of this structure is required as the management function of the long document. A large number of documents is like a set of various standard documents that are operated in the organization, and it is necessary to systematically manage the documents created in multiple departments of the organization.

According to the present invention, it becomes possible to meet such a requirement, and it is possible to realize an environment satisfying new needs in document management by applying it to a client / server type system or the like.

[Brief description of drawings]

FIG. 1 is an explanatory view of the principle of the present invention, FIG. 2 is an example of a logical structure of a document database according to an embodiment of the present invention, FIG. 3 is an example of a tree-structured management table according to an embodiment of the present invention, 4 is an example of a dynamic link management table according to an embodiment of the present invention, FIG. 5 is an example of a version number management table according to an embodiment of the present invention, and FIG. 6 is a shared management according to an embodiment of the present invention. An example of a table, FIG. 7 is an example of a data structure for managing a storage structure in one embodiment of the present invention, FIG. 8 is a system configuration of one embodiment of the present invention, FIG. 9 is an example of a conventional document management system, FIG. 10 shows an example of a conventional document management file structure. In the figure, 10 is a data processing device, 11 is a tree structure operation means, 12 is a logical structure management means, 13 is a storage structure management means, 14 is a cabinet, 15a and 15b are drawers, 16 is a physical structure management means, and 17 is a magnetic structure. A disk device, 18 represents an optical disk device.

Claims (2)

[Claims] 1. A document management processing apparatus in a data processing system having a function of managing a plurality of documents by a container of a plurality of layers, wherein a logical relationship between a plurality of documents or document elements is classified into a class and a class subordinate. Structure management means for managing by a logical structure of a tree structure consisting of a plurality of subclasses of the above and the entities corresponding to documents or document elements connected under the class or subclass, and at least creating / updating the above tree structure A tree structure operation means for performing an operation including deletion, and a storage structure management means for managing a storage structure for mapping a logical structure based on the tree structure to a physical structure indicating an actual physical storage location of a document or a document element And a document management processing device. 2. The document management processing apparatus according to claim 1, further comprising a physical structure management unit that manages a storage location of an actual physical storage medium of a document or a document element.