JP2004185180A - Data management program and data management system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To easily and readily display a number of file groups (object groups) in a plurality of dimensional tree structures so as to be operable. <P>SOLUTION: Objects include a file object directly associated with entity data (file) by a pointer (PTR) and a folder object showing a folder. Each object has link information (LINK). The link information comprises an upper layer link (Upper) showing an object of upper layer, a coordinate layer link (Pre) and (Suc) showing an object of coordinate layer, and a lower layer link (Lower Suc) and (lower Pre) showing an object of lower layer. The link information is provided in each of a plurality of dimensions. The link information of each dimension is referred to, whereby the object can be displayed in the tree structure of this dimension. The operation to the object is reflected to the link information or the like. <P>COPYRIGHT: (C)2004,JPO&NCIPI

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a data management program and a data management system for managing various data (files) stored in a storage device.
[0002]
[Prior art]
For example, in various computers such as personal computers, workstations, and servers, various data files such as a document data file, a graphic data file, and an image data file (hereinafter simply referred to as “files”) are stored in an auxiliary storage device such as a hard disk device. Calls) are stored in large numbers. The file can be stored in a folder (also called a directory), and another folder (subfolder) can be formed in the folder. The folder can be given an appropriate name.
[0003]
For example, a group of files of the same type or a group of files related to each other are stored in a folder with an appropriate name and organized, so that they can be stored in a hierarchical structure such as a tree structure. The existence of a group of files stored in the auxiliary storage device can be visually confirmed by a database program such as a file management manager.
[0004]
Usually, a file is placed on a specific layer in a layered storage structure by a user or an application program that generates the file. The user can confirm the storage structure in the storage device by using one kind of predetermined tree structure.
[0005]
On the other hand, various techniques for displaying the same data in a plurality of different modes have been proposed (for example, Patent Literature 1, Patent Literature 2, Patent Literature 3, and Patent Literature 4).
[0006]
[Patent Document 1]
JP-A-7-64760
[0007]
[Patent Document 2]
JP-A-10-124278
[0008]
[Patent Document 3]
JP-A-5-334032
[0009]
[Patent Document 4]
JP-A-7-191891
[0010]
[Problems to be solved by the invention]
A file management manager attached to an OS (Operating System) can only display a hierarchical storage structure of a file according to one type of (one-dimensional) association (for example, in a tree structure). However, there is a case where it is desired to sort and arrange the same file group with a different tree structure and perform browsing, operation, and the like. For example, there is a case where a group of files classified for each customer is newly classified and grasped for each product type and each process.
[0011]
When trying to represent the hierarchical storage structure of a file group by various kinds of classifications, that is, by multidimensional association, a simple method is to copy the file group by the number of dimensions or set a link. . However, when a plurality of copies of the same file are made, the storage capacity is significantly increased, and it takes time and effort to set a link. In addition, since the file can be operated for each dimension, it is necessary to synchronize the contents of the copied files for each dimension. In the case of link setting, if the original file at the link destination is moved or deleted, there is a possibility that the link is broken and cannot be referenced.
[0012]
On the other hand, in a conventional database technology such as RDMS (Relational DataBase Management System) or the like, in order to browse data in a multi-dimensional manner, after defining the structure of the database, the object of the file and the association between the objects are programmed. There is a need to. Therefore, it is necessary to redefine the database structure and the like every time the dimension specifications and the like change, and it takes a great deal of time to construct and maintain a multidimensional database.
[0013]
Therefore, the present invention has been made in view of the above-mentioned problem, and an object of the present invention is to provide a data management system capable of easily managing data in multiple dimensions and easily performing maintenance such as changing or adding dimensions. A management program and a data management system are provided. Other objects of the present invention will become clear from the description of the embodiment described later.
[0014]
[Means for Solving the Problems]
The data management program according to the present invention introduces management data having a structure unique to the present invention, acquires a group of management data, displays the data in a selected specific dimension, and receives an operation request from a user. Reflected in the management data group.
[0015]
That is, the management data is directly or indirectly associated with the entity data and includes link information indicating a multidimensional hierarchical storage structure. The acquisition function acquires at least one or more management data. The display function displays the acquired management data in a hierarchical storage structure in the selected dimension based on the link information of the selected dimension. Then, the reflection function reflects the operation on the displayed management data on the management data.
[0016]
There are at least two types of management data: entity data management data directly associated with the entity data, and storage destination management data defined as a virtual storage location of the entity data. The relationship with other management data in a plurality of dimensions is defined for each dimension.
[0017]
As a virtual storage destination of the entity data, a hierarchy called a folder or a directory can be given. The entity data management data is directly associated with the entity data by, for example, a pointer. The storage destination management data is associated with a storage location where entity data is stored. Each of the management data includes link information that defines a relationship between each of the plurality of dimensions and other management data in the dimension.
[0018]
The management data includes link information in a plurality of dimensions. Therefore, the management data group acquired from the storage device can be displayed in the form of each dimension. For example, for each of the management data, if the first-dimensional link information is specified by “customer” and the second-dimensional link information is specified by “product”, the first-dimensional link information is referred to. Accordingly, each management data can be displayed in a hierarchical storage structure "by customer", and similarly, each management data can be displayed in a hierarchical storage structure "by product" based on the two-dimensional link information. be able to. Since each of the management data is associated with the entity data, the user sees that the entity data is stored in a predetermined format in each dimension. When the user newly generates, moves, or deletes the management data, the operation content is reflected in the management data. Therefore, it is possible to correspond to a large number of dimensions only by changing the logical link information without redefining the database structure and the like as in the prior art.
[0019]
The acquisition function, the display function, and the reflection function can be activated for each of the selected dimensions, and can simultaneously display and operate each management data for each of the selected multiple dimensions.
[0020]
For example, the first-dimensional tree structure and the second-dimensional tree structure can be simultaneously displayed on the screen, and the management data can be operated in each tree structure. The user can select an arbitrary plurality of dimensions from a plurality of dimensions specified in the link information and simultaneously display them.
[0021]
In a preferred embodiment, the link information includes a first link indicating management data located in an upper layer of the self, a second link indicating management data located in the same layer in front of the self, and a link A third link located rearward in the layer, a fourth link located forward in its lower layer, and a fifth link located rearward in its lower layer.
[0022]
A data management system according to another aspect of the present invention includes first storage management means for storing and managing a plurality of entity data, and link information respectively associated with the entity data and indicating a multidimensional hierarchical storage structure. Storage management means for storing and managing a plurality of management data, and management data acquired from the second storage management means displayed in a hierarchical storage structure of a selected dimension. Data management means for reflecting a user operation on the data in the management data. The data management means obtains at least one or more management data from the second storage management means, and the obtained management data is selected based on the link information of the selected dimension. Display means for displaying in a hierarchical storage structure in the displayed dimension, and reflecting means for reflecting a user operation on the displayed management data in the management data, wherein the data management means includes a plurality of selected ones. Each hierarchical storage structure can be displayed and managed by dimension.
[0023]
A data management method according to a preferred embodiment includes a step of acquiring at least one or more pieces of management data that are associated with entity data and include link information respectively indicating a multidimensional hierarchical storage structure; Based on the link information of the selected dimension, a step of displaying the selected dimension in a hierarchical storage structure, and a step of reflecting the operation on the displayed management data in the management data.
[0024]
The data structure according to the preferred embodiment is a data structure of management data used in the data management system, and includes an identification information recording area in which identification information for identifying itself and others is recorded, and self name information is recorded. A name information recording area, a pointer recording area in which a pointer to entity data is recorded, and a link information recording area in which link information indicating a relationship with other management data is recorded. Further, in the link information recording area, a first link indicating management data located in a layer higher than the self, a second link indicating management data positioned ahead in the same layer as the self, and the same link as the self. The information of the third link located rearward in the layer, the information of the fourth link located forward in the lower layer of the own layer, and the information of the fifth link located rearward in the lower layer of the own layer are stored in a multi-dimensional hierarchical storage structure. Are recorded so that they can be changed.
[0025]
As described above, by providing the link information recording area for recording the link information indicating the relationship with the other management data so as to be changeable for each of the plurality of dimensions, the management data can be arranged and displayed in different dimensions. In addition, an operation (for example, movement, deletion, generation, etc.) on the management data can be reflected in the link information recording area.
[0026]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, an embodiment of the present invention will be described in detail with reference to FIGS. 1 to 18 using a file management system as an example.
[0027]
First, FIG. 1 is a configuration explanatory diagram showing an overall outline of a file management system as a data management system. The file management system can be realized on various computers such as a personal computer, a workstation, a server, a portable information terminal, and a mobile phone. The file management system can be used for managing files stored in a local storage device, and also for managing files stored in a storage device on a network. When using via a network, for example, like an ASP (Application Service Provider), files of each user are stored in a server on the network, and a file management program described later is operated on the server. Thereby, a file management function can be provided to each user from the server via the network.
[0028]
The file management unit 10 displays a large number of files (objects) stored in the storage device in a tree structure desired by the user in response to a request from the user, and receives an operation from the user. Although details of the object will be described later, the object is associated with a file or a folder, and the user can confirm the storage structure of the file and perform a file operation through the object.
[0029]
The file management unit 10 has an object operation unit 11, a screen display unit 12, and an object acquisition unit 13. The object operation unit 11 receives a file operation (for example, generation of a new file, change of a storage destination folder (movement of a file, deletion of a file, and the like)) from a user, and reflects the file operation on an object associated with the file or the folder. The screen display unit 12 arranges and displays a large number of objects acquired from the object management unit 20 by the object acquisition unit 13 in a tree structure of a specific dimension designated by the user. The object group is obtained from the object management unit 20 in response to an initialization request, a user operation, etc. Here, it should be noted that the screen display unit 12 is provided for each of a plurality of dimensions desired by the user, that is, Multiple types of tree structures can be displayed on the screen, and the user can operate each tree structure Located in.
[0030]
The output of the screen display unit 12 is delivered to the display driver 4 of the user terminal via a communication network CN such as the Internet, and is output to the display 3 of the user terminal. The user operates the object displayed on the display 3 via the input device 1 such as a mouse, a tablet, and a keyboard switch while looking at the tree structure displayed on the display 3. The user operation is passed from the input device driver 2 to the object operation unit 11 via the communication network CN. The object operation unit 11 updates the content of each object related to the operation according to the operation from the user.
[0031]
The object management unit 20 manages a large number of objects 21 stored in the storage device. However, in the initial stage of the file management system, there is a case where only one or a small number of objects are managed. The entity data management unit 30 manages a large number of entity data (files) 31 stored in the storage device.
[0032]
Each object 21 is associated with entity data (file) 31 or a folder. For example, in the illustrated example, the first and second objects 21 are directly associated with the first and second entity data 31, respectively. Since the third and fourth objects 21 symbolize folders, they are not directly associated with the entity data 31. The folder object is indirectly associated with the entity data 31 as a storage destination of the entity data 31.
[0033]
Next, the structure of the object will be described with reference to FIG. As shown in FIG. 2A, each object is converted into identification information “ID” for identifying itself and another object, name information “Name” of the object, and entity data associated with the object. , Pointer information “LINK” indicating a relationship between each of the plurality of dimensions and other objects, and other information (to be described later with reference to FIG. 3). In the case of an object indicating a folder, a pointer is not described, and for example, null data and the like are stored.
[0034]
Here, the link information of each dimension has five links, respectively. As shown in FIG. 2B, the five links include a link “Upper” to an upper-layer object indicating an object located in the upper layer of the self, and a link to an object located in front of the same layer as the self. A link “Pre”, a link “Suc” to an object located at the same layer and rearward in the same layer as the link, a link “Lower Pre” to an object positioned forward in the lower layer of the self, and a link “Lower Pre” to the lower layer in the self. This is a link “Lower Suc” to the located object. These one set of links are set for each of a plurality of dimensions. The front object indicates an object located before the self, and the rear object indicates an object located next to the self. File search and the like are performed in this order.
[0035]
FIG. 2C is a topological explanatory diagram of a link centered on an object of a certain folder (directory Dir A). The folder (Dir A) is provided with five links of “Upper”, “Pre”, “Suc”, “Lower Pre”, and “Lower Suc”. The directory or file objects "dir / file 1" to "dir / file 4", which are located in the lower layers of "Dir A", respectively, have a relation of the same layer.
[0036]
A link “Lower Pre” indicating an object located ahead of the lower layer when viewed from “Dir A” is connected to the object “dir / file 1”. Further, a link “Lower Suc” indicating an object located behind the lower layer is connected to another object “dir / file 4”. Each of the objects “dir / file 1” to “dir / file 4” in the lower layer has a link “Upper” to the upper layer object “Dir A”. Although not shown, each of the objects “dir / file 1” to “dir / file 4” may include links “Lower Pre” and “Lower Suc” to lower layers.
[0037]
As described above, by referring to the links in a specific dimension of each of the objects “Dir A” and “dir / file 1” to “dir / file 4”, the file management unit 10 is configured as shown in FIG. Such a hierarchical storage structure can be grasped. As will be described later, other link structures besides those shown in FIG. 2C can be adopted.
[0038]
FIG. 3 is an explanatory diagram illustrating a specific example of an object. As described in FIG. 2A, each object includes an ID, a name, a pointer (PTR to Real Entity), and link information. Here, it should be noted that the link information is defined for each dimension (Dimension-1 to N). Characters such as “one-dimensional”, “two-dimensional”, and “N-dimensional” in FIG. 3 are shown for convenience of description, and are not essential components of the object.
[0039]
Other information “Attributes” specifies various attributes of the object. Examples of the attribute include an object type (a folder object, a file object, a root object, and the like), a keyword that can be used for searching, and a comment sentence.
[0040]
When an object is deleted in a dimension, the link in that dimension is deleted. When an object is moved in a certain dimension, the link in that dimension is rewritten according to the destination.
[0041]
FIG. 4 shows an example of a screen when file management is performed using the file management system 10. As described above with reference to FIG. 1, the user can perform file management in a plurality of desired dimensions by logging in to the file management system on the network.
[0042]
As shown in FIG. 4, the user can simultaneously display a plurality of types of tree structures T1 and T2 on the screen. There is no limit on the number of tree structures that can be displayed. However, the number of tree structures that can be displayed depends on the screen size and the like. For example, various menus such as “edit folder” M1, “edit file” M2, “input text” M3, and “search” M4 can be provided at the top of the screen.
[0043]
On the left side of FIG. 4, a tree structure T1 in which a certain file group is arranged by “customer” is displayed, and on the right side, a tree structure T2 in which the same file group is arranged by “document” is displayed. In each of the tree structures T1 and T2, different folders are arranged in the same “my Bookcase” folder. As a result, the user can arrange and display the same file group “Files 1 to 9” in a tree structure suitable for the purpose and operate the same.
[0044]
Next, the operation of the present embodiment will be described with reference to FIGS. Note that the flowchart shown in the figure shows an outline of the operation, and is different from an actual program. First, the overall operation will be described with reference to FIGS.
[0045]
FIG. 5 shows a screen display process. The screen display unit 12 of the file management unit 10 acquires the object group from the object management unit 20, arranges the object group at a predetermined position based on the link information of the dimension selected by the user, and displays the object group on the screen. (S1). Then, the file management unit 10 waits for an operation from the user (S2).
[0046]
When an operation is input from the user, it is determined whether the operation is an operation on an object or an operation on an object other than the object (S3). If the user's operation is an operation on the object such as creation of a new object, deletion of the object, movement of the object, copying of the object, or change of the name of the object (S3: YES), the content of the operation of the user Is passed to the operated object (S4).
[0047]
If the operation is for an object other than an object (S3: NO), it is determined whether the operation is a window operation (S5), a file operation (S7), or an end operation (S9). In the case of an operation on a window, the window is operated (S6), and in the case of an operation on a file, the file is operated (S8). In the case of a termination operation, termination processing is performed (S9). The above processing is repeated until the end operation is performed.
[0048]
FIG. 6 shows a process for operating an object. First, an object group is acquired from the object management unit 20 (S11). Next, whether the user operation is to add an object (S12), delete an object (S14), change an object link (S16), (S18).
[0049]
When an operation of adding an object is performed, a process of creating a new object is performed (S13). When the operation of deleting the object is performed, the object is deleted (S15). When an operation of moving the object is performed, a process of changing the link information of the object is performed (S17). When the content of the object is operated, the operation is transferred to the object (S19). Then, a permanent process for reflecting these operation contents on the object is performed, and the process ends (S20).
[0050]
The above is the outline of the operation of the file management system. Next, a more detailed operation will be described.
[0051]
FIG. 7 is a flowchart in a case where an object group is displayed in a tree structure in a certain specific dimension m. First, referring to the link information of the root object (generally, the root object is a folder), an object connected by the link “Lower Suc” of the selected dimension m is detected. An object connected to the link “Lower Suc” is set as a root object on the tree structure display, and is set in ObjectX (S21). “ObjectX” is a variable. Then, in the dimension m, another object located in the same layer as the ObjectX is displayed (S22).
[0052]
Next, FIG. 8 shows a process for displaying another object of the same hierarchy (of the same dimension) as the object set in the variable ObjectX in a specific dimension m.
[0053]
First, as an end condition, the ID of ObjectX is set in ObjectSID (S31). ObjectSID is a variable. Next, the first set ObjectX name is displayed in a tree structure (S32). When the object set in ObjectX indicates a folder, the object is displayed in a folder shape (folder icon). In the case of an object indicating a file (or actual data), it is displayed (file icon) as a file (or actual data).
[0054]
Next, a lower-level object connected by a link “Lower Suc” with the dimension m of ObjectX is set to a variable ObjectY (S33). It is determined whether the ID of ObjectY matches the ID of ObjectX (S34). If the IDs do not match (S34: NO), the object is set in the same layer as the object currently set in ObjectY in the dimension m. The object located is displayed (S35).
[0055]
Next, an object connected to the object set in ObjectX by the link “Suc” of the same layer in the dimension m is set in ObjectY (S36). If the IDs of ObjectY and ObjectX do not match and the ID of ObjectY does not match the first set ObjectSID (S37: NO, S38: NO), the value of ObjectY is set to ObjectX (S39). It returns to S32. On the other hand, if the IDs of ObjectY and ObjectX match, or if the ID of ObjectY matches ObjectSID (S37: YES, S38: YES), the process ends. Through the above processing, a tree can be displayed in a specific dimension m.
[0056]
Next, FIG. 9 shows a process for moving an object A to a lower layer of another object B in a certain dimension m. First, the object A is separated at the dimension m (S41), and then the object A is added to the lower layer of the object B at the dimension m (S42).
[0057]
Next, FIG. 10 shows a process of separating an object A at a dimension m. It is a detail of S41 in FIG.
[0058]
First, an object connected by a link “Upper” in the dimension m of the object A is set to a variable ObjectX (S51). Next, a variable ObjectY1 is set as an object connected by the lower layer link “Lower Suc” in the dimension m of ObjectX, and a variable ObjectY2 is set as an object connected by the lower layer link “Lower Pre” in the dimension m (S52). On the other hand, the variable ObjectZ1 is set as an object connected by the peer layer link "Suc" in the dimension m of the separated object A, and the variable ObjectZ2 is set as an object connected by the peer layer link "Pre" (S53).
[0059]
Then, the ID of the object A is compared with the IDs of ObjectY1 and ObjectY2 (S54). When all three IDs match, the links "Lower Suc" and "Lower Pre" in the dimension m of ObjectX are connected to ObjectX itself (S55). That is, this is a case where no object is connected to the lower layer of ObjectX by separating the object A.
[0060]
If the IDs of the three parties do not match, the peer layer link “Pre” in the dimension m of Object Z1 is set to ObjectZ2, and the peer layer link “Suc” in the dimension m of ObjectZ2 is set to ObjectZ1 (S59).
[0061]
If the IDs of the three parties do not all match or do not match, that is, if only the IDs of any two parties match, it is determined whether the ID of ObjectZ1 matches the ID of ObjectZ2 ( S56). When both IDs match, only one object exists in the lower layer of the object A. Therefore, the link pointing to the object A to be separated among the lower layer links “Lower Suc” or “Lower Pre” in the dimension m of ObjectX is connected to ObjectZ1 (S57). On the other hand, when the ID of the Object Z1 and the ID of the Object Z2 do not match (S56: NO), it is a case where a plurality of objects exist in the lower layer of the object A. Therefore, of the lower layer links “Lower Suc” or “Lower Pre” in the dimension m of ObjectX, the link pointing to the object A is connected to the ObjectZ1 or ObjectZ2 that is not connected to the one not pointing to the object A (S58).
[0062]
After performing the processing of S55, S57, and S58, the above-described S59 is performed, and finally, the upper-layer link “Upper” and the same-layer links “Pre” and “Suc” in the dimension m of the object A are set to the object A It is set to itself (S60).
[0063]
Next, FIG. 11 shows the details of S42 in FIG. 9, and shows the processing when the separated object A is added to the lower layer of the object B.
[0064]
First, the objects connected to the lower layer links “Lower Suc” and “Lower Pre” in the dimension m of the object B are set to ObjectX1 and ObjectX2, respectively (S61). Further, the upper layer link “Upper” in the dimension m of the object A is set to the object B (S62), and the lower layer link “Lower Pre” in the dimension m of the object B is set to the object A (S63).
[0065]
Then, the ID of ObjectX1 is compared with the ID of object B, and it is determined whether or not both IDs match (S64). When the two IDs do not match (S64: NO), it is a case where at least one or more objects exist in the lower layer of the object B to which the object A is added. Therefore, ObjectX1 and ObjectX2 are respectively set to the peer layer links “Pre” and “Suc” in the dimension m of the object A, and the peer layer link “Suc” in the dimension m of the ObjectX1 and the peer layer link “Pre” in the ObjectX2. Then, an object A to be newly added is set (S65).
[0066]
On the other hand, if the ID of the Object X1 matches the ID of the object B (S64: YES), it means that there is only one object in the lower layer of the object B. The object A is set in "Lower Suc" (S66).
[0067]
Next, FIG. 12 shows a process for connecting an object A of dimension n to a lower layer of an object B of dimension m.
[0068]
First, ObjectX1 and ObjectX2 are set as objects connected by the lower layer links “Lower Suc” and “Lower Pre” in the dimension m of the object B (S71). Also, the upper layer link “Upper” in the dimension m of the object A is set to the object B (S72), and the lower layer link “Lower Pre” in the dimension m of the object B is set to the object A (S73).
[0069]
Then, the ID of the Object X1 is compared with the ID of the object B, and it is determined whether or not both IDs match (S74). If the two IDs do not match (S74: NO), ObjectX1 and ObjectX2 are set to the peer layer links "Pre" and "Suc" in the dimension m of the object A, respectively, and the peer layer link "Suc" in the dimension m of the ObjectX1 is set. Then, the object A is set to the same layer link “Pre” in the Object X2 (S75). On the other hand, if the ID of ObjectX1 matches the ID of the object B (S74: YES), the object A is set to the lower layer link “Lower Suc” in the dimension m of the object B (S76).
[0070]
Next, FIG. 13 shows a process for displaying an object as a file or actual data connected to each object group in a matrix around each object group connected to the object A of dimension m and the object B of dimension n. It is a flowchart.
[0071]
First, from the lower-level object connected to the lower-layer link “LowerSuc” in the dimension m of the object A, an object group connected to the lower-layer link “Suc” in the dimension m of the object is set to ObjectX1. It is set (S81). From the lower-level object connected to the lower-layer link “LowerSuc” in the dimension n of the object B, an object group connected to the lower-layer link “Suc” in the dimension n of the object B is set to ObjectY1... S81).
[0072]
Next, for the mxn combination of the extracted ObjectX1... Xm and ObjectY1... Yn, ObjectXi (i = 1... M) of dimension m and ObjectYj of dimension n (j = 1. An object is displayed as a file or actual data connected to n) (S82).
[0073]
Next, FIG. 14 shows a process of displaying an object as a file or actual data that connects ObjectX of dimension m to ObjectY of dimension n.
[0074]
First, as an end condition of the process, the ID of ObjectX is set to ObjectSID (S91). Next, when ObjectX represents a file or actual data, and ObjectY is connected to an upper layer of ObjectX in dimension n, a link to ObjectX is displayed (S92). In addition, the object connected by the lower layer link “Lower Suc” in the dimension m of ObjectX is set to ObjectZ (S93).
[0075]
Then, it is determined whether or not the ID of ObjectZ and the ID of ObjectX match (S94). If the IDs do not match (S94: NO), the ObjectZ in the dimension m is converted to the file or the file connected to the ObjectY in the dimension n. An object is displayed as actual data (S95).
[0076]
On the other hand, if the ID of ObjectZ and the ID of ObjectX match (S94: YES), the object connected by the peer layer link “Suc” in the dimension m of ObjectX is set to ObjectZ (S96). Then, it is determined whether or not the ID of ObjectZ and the ID of ObjectX match (S97). If both IDs match (S97: YES), there is no other object in the peer layer, so the processing is performed. finish.
[0077]
When the ID of ObjectZ and the ID of ObjectX do not match (S97: NO), it is further determined whether or not the ID of ObjectZ matches the ObjectSID (S98). If the two IDs match, it means that all the objects have been inspected and displayed, and the process ends. On the other hand, if the ID of ObjectZ does not match ObjectSID (S98: NO), ObjectZ is set to ObjectX (S99), and the process returns to S92.
[0078]
FIG. 15 shows a process for displaying ObjectX when ObjectX represents a file or actual data and is connected to ObjectY in an upper layer of dimension n.
[0079]
First, it is determined whether ObjectX represents a file or actual data (S101). Further, when ObjectX indicates a file or actual data (S101: YES), ObjectX is set to ObjectZ1 (S102). Further, an object connected by an upper layer link “Upper” in the dimension n of the Object Z1 is set in the Object Z2 (S103).
[0080]
Then, it is determined whether or not the ID of ObjectZ2 and the ID of ObjectZ1 match (S104). If the IDs match, the process ends. When both IDs do not match, it is further determined whether or not the ID of ObjectZ2 matches the ID of ObjectY (S105). When the ID of ObjectZ2 and the ID of ObjectY match, the name of ObjectX is displayed, and ObjectX is displayed as a file or actual data icon (S107). On the other hand, if the ID of ObjectZ2 and the ID of ObjectY do not match (S105: NO), ObjectZ2 is set to ObjectZ1 (S106), and the process returns to S103.
[0081]
FIG. 16 is an explanatory diagram showing an example of a matrix display for automatically summarizing an object group associated with each of two different types of dimensions. On the horizontal axis, a folder object group belonging to the dimension of “Theme 1” is arranged, and on the vertical axis, a folder object group belonging to the dimension of “Theme 2” is arranged.
[0082]
In the present embodiment, as shown in FIG. 16, it is possible to check at a glance how files belonging to each folder object group of a certain dimension are distributed to folder object groups of another dimension. ing. That is, a function of automatically summarizing management data associated with each of the selected dimensions by referring to the link information of the management data group for each of the plurality of selected dimensions and displaying the data in a matrix. "Is provided on the screen display unit 12.
[0083]
As shown in the lower part of FIG. 16, when cells associated with each of a folder having one dimension and another folder having the other dimension are selected with a mouse pointer or the like and clicked, the two dimensions are obtained. Files (or subfolders) belonging to both folders can also be displayed. In addition to displaying the tree structures T1 and T2 of each dimension, it is also possible to display in the window W1 a group of files that belong to a predetermined folder of each of the trees T1 and T2.
[0084]
FIG. 17 shows a modification of the link structure of an object.
[0085]
In the link structure shown in FIG. 17A, unlike the link structure shown in FIG. 2C, the object itself does not directly have the lower layer links “Lower Suc” and “Lower Pre”, but instead has the inside of the object. , A queue for indicating the lower layer link relationship is provided. Then, a link to another object located in the lower layer is set using this queue as an alter ego for lower layer link definition.
[0086]
The difference between the other link structure shown in FIG. 17B and the link structure shown in FIG. 2C is that, first, the object directly has the lower layer links “Lower Suc” and “Lower Pre”. Instead, the link to the lower layer is set via a queue provided in the object. Second, the object does not have the upper layer link “Upper”. In order to acquire an object of an upper layer, a queue is detected by following the same layer links “Pre” and “Suc”. What is necessary is just to acquire the object having the queue as an upper layer object.
[0087]
Another difference between the link structure shown in FIG. 17C and the link structure shown in FIG. 2C is that the object itself does not directly have the lower layer links “Lower Suc” and “Lower Pre”, It has a bidirectional link with only one lower layer object among the objects belonging to the layer.
[0088]
The other link structure illustrated in FIG. 18 is different from the link structure illustrated in FIG. 2C in that the object itself does not directly have the lower layer links “Lower Suc” and “Lower Pre”, and the object itself belongs to the lower layer. Among them, only one object has a bidirectional link. Further, among the objects belonging to the same layer, there is only one object having the link “Upper” to the upper layer. That is, there is only one object having a link with the parent object in the group of objects in the same layer. By tracing the objects of the same layer with the same layer links “Pre” and “Suc” and detecting the object having the link to the object of the higher layer, the object located at the upper level of the self can be acquired.
[0089]
According to the present embodiment, unlike the prior art, the file group is copied by the number of dimensions, or the association between the objects is not programmed one by one. The multidimensional association can be displayed in an easy-to-understand manner, and the object operation by the user can be immediately reflected on the object. Therefore, in the present system, it is possible to determine the association of the object group over multiple dimensions through trial and error, and it is possible to efficiently produce a file management system capable of simultaneously referring to multiple dimensions.
[0090]
Also, as a result of adopting the above configuration, a matrix display function for automatically totaling and displaying objects associated with the selected two dimensions only by the user selecting an arbitrary two-dimensional among the multi-dimensions. Can be easily realized.
[0091]
The embodiments of the present invention described above are examples for explaining the present invention, and are not intended to limit the scope of the present invention only to the embodiments. Those skilled in the art can implement the present invention in various other modes without departing from the gist of the present invention.
[Brief description of the drawings]
FIG. 1 is a block diagram showing an overall outline of a data management system according to an embodiment of the present invention.
FIGS. 2A and 2B are explanatory diagrams showing the structure of an object. FIG. 2A shows the structure of an object, FIG. 2B shows the relationship between a link and an object, and FIG. 2C shows the link structure.
FIG. 3 is an explanatory diagram showing a more detailed example of the structure of an object.
FIG. 4 shows an example of a multi-tree screen for simultaneously referring to a plurality of tree structures.
FIG. 5 is a flowchart of a screen display process.
FIG. 6 is a flowchart illustrating an object operation process.
FIG. 7 is a flowchart showing a tree display of objects in a dimension m.
FIG. 8 is a flowchart for displaying an object of the same hierarchy in a dimension m.
FIG. 9 is a flowchart when an object is moved to another object in a dimension m.
FIG. 10 is a flowchart when an object is separated at a dimension m.
FIG. 11 is a flowchart for adding a separated object to a lower layer of another object.
FIG. 12 is a flowchart in a case where an object of a certain dimension is added to a lower layer of an object of another dimension.
FIG. 13 is a flowchart in a case where objects connected to respective object groups are displayed on a matrix centered on an object group connected to an object of one dimension and an object of another dimension.
FIG. 14 is a flowchart in a case where an object of a certain dimension is displayed as an object connected to an object of another dimension.
FIG. 15 is another flowchart for displaying an object.
FIG. 16 is a screen example in a case where an object group associated with each of two selected dimensions is automatically tabulated and displayed in a matrix.
FIG. 17 is an explanatory diagram showing a modification of the link structure of an object.
FIG. 18 is an explanatory diagram showing still another link structure of an object.
[Explanation of symbols]
1 Input device
2 Input device driver
3 Display
4 Display driver
10 File management unit
11 Object operation unit
12 Screen display
13 Object acquisition part
20 Object Management Department
21 Objects
30 Entity Data Management Department
31 Entity data

Claims (4)

An acquisition function (13) for acquiring at least one or more management data (21) directly or indirectly associated with the entity data (31) and including link information indicating a multi-dimensional hierarchical storage structure;
A display function (12) for displaying the obtained management data (21) in a hierarchical storage structure in the selected dimension based on the link information of the selected dimension;
A reflection function (11) for reflecting an operation on the displayed management data (21) on the management data (21), and
The management data (21) includes at least entity data management data directly associated with the entity data (31), and storage destination management data defined as a virtual storage location of the entity data. There are two types,
Further, in the data management program, the link information has a relationship with the other management data (21) in the plurality of dimensions defined for each dimension. The acquisition function (13), the display function (12), and the reflection function (11) can be activated for each selected dimension, respectively, and the management data ( 2. The data management program according to claim 1, wherein 21) is displayed and operable. The link information includes a first link (Upper) indicating management data (21) located in an upper layer of the self, and a second link (Pre) indicating management data located in the same layer and in front of the self. A third link (Suc) located rearward in the same layer as the self, a fourth link (Lower Pre) located forward in the lower layer of the self, and a fifth link (Back) located in the lower layer of the self. 3. The data management program according to claim 2, further comprising a link (Lower Suc). First storage management means (30) for storing and managing a plurality of entity data (31);
A second storage management unit (20) that stores and manages a plurality of management data (21) each including link information respectively associated with the entity data (31) and indicating a multidimensional hierarchical storage structure; ,
The management data (21) acquired from the second storage management means (20) is displayed in a hierarchical storage structure of a selected dimension, and a user operation on the displayed management data (21) is performed by the user. Data management means (10) for reflecting the data in data (21).
The data management means (10)
Acquisition means (13) for acquiring at least one or more management data from the second storage management means (20);
Display means (12) for displaying the obtained management data (21) in a hierarchical storage structure in the selected dimension based on the link information of the selected dimension;
Reflecting means (11) for reflecting a user operation on the displayed management data (21) in the management data (21);
The data management system (10), wherein the data management means (10) can display and manage each hierarchical storage structure in a plurality of selected dimensions.

Images