JPH06348575A - Data base controller - Google Patents

Abstract

PURPOSE:To control and dynamically change access right in record units and to facilitate complicated access right control by providing an access right management table and access right control fields by records and setting the access right therein as to the data base controller which performs access control over a data base, record by record. CONSTITUTION:The data base controller is equipped with the access right control fields 7 which are provided by the records 6 of tables 5 of the data base and have access right control information 8 optionally set and the access right management table 9 wherein the qualifications of access right of users are registered by the tables 5 of the data base and the qualifications of access right by the users corresponding to the access right control information 8 set in the access right control fields 7 are previously registered; and the access right control by the users is performed in record-6 units.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a database control device for controlling access to each record of a database.

[0002]

2. Description of the Related Art Conventionally, data protection of a database is realized by giving a fixed access restriction to the entire database. Specifically, the setting of the user's access right to the database has been performed on a database basis, a table basis, and a field basis.

[0003]

For this reason, it is not possible to restrict access on a record-by-record basis within one table, and the access right must be changed for the entire table, thus setting a complicated access right. There was a problem that I could not do.

The present invention solves these problems.
The purpose is to provide an access right management table and an access right control field for each record, and set them to realize the control and dynamic change of the access right for each record and to easily realize the complicated access right control. There is.

[0005]

FIG. 1 is a block diagram showing the principle of the present invention. In FIG. 1, the access right control field 7 is a field provided for each record 6 of the table 5 of the database 4 and for arbitrarily setting the access right control information 8.

The access right management table 9 registers the access right qualification of the user for each table 5 of the database 4 and the access right qualification of each user for the access right control information 8 set in the access right control field 7. Is a table for registering in advance.

[0007]

According to the present invention, as shown in FIG.
The access right control field 7 for arbitrarily setting the access right control information 8 is provided for each record 6 of the table 5 of FIG. The access right management table 9 in which the qualification of the access right for each user to the access right control information 8 set in No. 7 is registered in advance is provided, and the access right control for each user is performed for each record 6.

A plurality of access right control fields 7 of the record 6 are provided and the access right management table 9 is provided.
The qualifications for each user corresponding to the access right control information 8 for each of the plurality of access right control fields 7 are registered respectively, and the access right of the result of the logical product operation of the plurality of registered qualifications is obtained to obtain a record 6 unit. The access right is controlled for each user.

Further, in response to a change instruction of the access right control field 7 from the user, the update qualification of this user is registered in the corresponding table 5 in the access right management table 9 and the access of the corresponding access right control field 7 is performed. When it is registered corresponding to the right control information 8 (when there is a plurality of registrations, it is updated as the access right of the result of the logical product operation), the corresponding access right control field 7 of the record 6 is changed. The access right control information 8 is changed.

Therefore, by providing the access right management table 9 and the access right control field 7 for each record 6, it becomes possible to control the access right for each record 6 set in these tables and to set the access right. It can be changed dynamically.

[0011]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Next, the construction and operation of an embodiment of the present invention will be described in detail with reference to FIGS.

FIG. 1 is a block diagram showing the principle of the present invention. Figure 1
In the above, the front end 1 is a processing device that receives a request for searching, updating, deleting, registering the database 4 from a host (not shown) or an application program, and returns the result. This front end 1
For example, at the time of search, notifies the access device 2 of the accepted user name and search condition, receives the record as a result, and returns the record to a host or the like not shown.

In response to the notified search instruction, the access device 2 checks whether the user has the right to search the table 5 by referring to the access right management table 9 or the record to be searched retrieved from the database 4. The access right control information 8 in the access right control field 7 is retrieved, and when the access right management table 9 is found to have the search right, the record is notified to the front end 1. , Record access check processing 21 and the like (described later with reference to FIGS. 2 to 7).

The record access check process 21 checks the access right of the user for each record (which will be described later with reference to FIGS. 2 to 7). The database engine 3 controls access to the database 4, and is composed of a search function 31, a registration function 32, an update function 33, a delete function 34, and the like here.

The search function 31 finds and retrieves the contents of the corresponding record 6 of the corresponding table 5 from the database 4. The registration function 32 registers the data instructed to be registered in the corresponding record 6.

The update function 33 updates the content of the record 6 instructed to be updated. The delete function 34 deletes the contents of the record 6 for which deletion has been instructed. The database 4 is a database in which data is registered in a hierarchical structure so that it can be easily searched.
The table TBL, the field FLD, and the record RD have a hierarchical structure.

The record 6 is provided with a plurality of access right control fields 7 for storing access right control information 8 in addition to fields for storing data. Here, AC
Two of F1 and ACF2 are the access right control field 7.

The access right control field 7 stores the access right control information 8 and can be arbitrarily changed by a user who has an update right (see FIG. 7). The user's access right q: search d: delete w: register / update in advance in the access right management table 9 in association with the numbers, character strings, etc., which are the access right control information 8 registered in the access right control field 7. Register and register the access right control field 7
The user's access right qualification for each record can be set arbitrarily.

The access right management table 9 is for registering the access right qualification for each record in advance for each user. Here, registration is performed as illustrated. For example: -DB1 TBL1 qdw = usr1, usr2, usr3, usr4, usr5 qw = usr6, usr7 q = * for the table TBL1 of the database DB1-A user who has the qualification of qdw (search, delete, register / update), usr1, usr2, usr3, usr4, us
r5.

The users having the qualification of qw (search, registration / update) are usr6 and usr7. -Users with the q (search) qualification are all users.

Next, When the value of the access right control information 8 of the access right control field ACF1 of the record is 0, the users having the qualifications of qdw (search, delete, register / update) are usr1, usr2, usr3, and A user with the qw (search, registration / update) qualification is u
sr4 and usr7, and the users with the qualification of q (search) are all users.

In the case of> = 0, the users having the qualification of qdw (search, delete, register / update) are usr1 and usr2, and the users having the qualification of q (search) are all the users. .

Similarly, the user has the illustrated qualifications for the ACF 2. The result of the logical product operation of these qualifications for each user is determined as an access right (which will be specifically described later with reference to FIG. 6).

Next, the search, update, delete, and registration of each record of the database 4 will be sequentially described in detail with reference to the flowcharts of FIGS. FIG. 2 shows a search flowchart of the present invention.

In FIG. 2, S1 gives a record search instruction. In S2, the search is accepted. In this case, the front end 1 of FIG. 1 accepts the record search instruction of S1. At the time of receiving a search, as shown in the figure: -database name-table name-field condition-user name is received.

In step S3, it is determined whether or not the database 4 is qualified to be searched. This refers to the access right management table 9 and determines whether or not the user name of the database name and table name instructed to search is registered as qualified for search (q). For example, since the user name usr1 is registered as q (search) = * (all users) for DB1 and TBL1 by referring to the access right management table 9 in FIG. 1, the qualification of search (q) is registered here. Since it is determined that it is present, YES is obtained and the process proceeds to S4. In the case of NO, since the database 4 is not qualified to search, the process ends (END).

In step S4, the record matching the search condition is searched for and the access right control information 8 of the record is taken out. For example, the access control information "1" of the ACF1 of the RD1 of the TBL1 of the DB1 and the access control information "abc" of the ACF2 of FIG.

In step S5, it is determined whether the user can search. S4
Based on the access right control information 8 fetched in step 3, the access right management table 9 is referenced to determine whether or not there is a search right (decision of the access right will be described later using FIG. 6).
In the case of YES, the record is passed to the user, and the series of search processing ends. On the other hand, in the case of NO, since there is no search right for the record, the record is removed from the search results and only the record having the search right is passed to the user in S7.

As described above, in response to the search instruction, the access right management table 9 is referred to, and when it is found that the database and the table for which the search instruction is issued have the search qualification, the contents of the record for which the search instruction is issued are displayed. The access right management table 9 is referred to based on the access right control information 8 in the access right control field 7 to determine whether or not there is a search right for the record, and when there is, the record is passed to the user. As a result, search control can be performed for each user in record units.

FIG. 3 shows a flow chart of the update of the present invention. In FIG. 3, S11 displays the search result.
This displays the search result according to the flowchart of FIG. 2 on the display.

In step S12, an update record is selected.
This is to select the record to be updated by the user from the records displayed on the display in S11.

In step S13, the update is accepted. At the time of accepting this update, as shown in the figure: -database name-table name-user name-update record ID is received.

In step S14, it is determined whether the database 4 is qualified to be updated. This refers to the access right management table 9 and determines whether the user name of the database name or table name instructed to be updated is registered for update / registration (w). For example, the user name usr1 is as shown in FIG.
Referring to the access right management table 9 of DB1, TBL
For 1 qdw (search, delete, update / register) = usr
Since it is registered as 1 ..., it is found here that the qualification of update / registration (w) is registered, so YES
Then, the process proceeds to S4. If no, database 4
There is no qualification for renewal, so it ends (END).

In step S15, it is determined whether the record can be updated.
This is based on the access right control information 8 extracted from the record of the update record ID, and refers to the access right management table 9 to determine whether the user is qualified to update the record (see FIG. 6). The decision of access rights will be described later). If yes, update the record,
finish. If NO, the process ends without updating.

As described above, in response to the update instruction, the access right management table 9 is referred to, and when it is determined that the database and the table for which the update instruction has been issued have the update qualification, the contents of the record for which the update instruction is issued are displayed. The access right management table 9 is referred to based on the access right control information 8 in the access right control field 7 to determine whether or not there is an update right for the record, and the record when it is present is updated. As a result, it becomes possible to perform update control for each user in record units.

FIG. 4 shows a deletion flowchart of the present invention. In FIG. 4, S21 displays the search result.
This displays the search result according to the flowchart of FIG. 2 on the display.

In step S22, a deleted record is selected.
This is to select the record to be deleted by the user from the records displayed on the display in S21. In S23, the deletion is accepted. At the time of accepting this deletion, as shown in the drawing, the database name, the table name, the user name, and the deleted record ID are received.

In step S24, it is determined whether or not the database 4 is qualified to be deleted. This refers to the access right management table 9 and determines whether or not the qualification of deletion (d) is registered for the user name for the database name and table name instructed to be deleted. For example, the user name usr1 refers to the access right management table 9 in FIG. 1, and qdw (search, delete, update / register) for DB1 and TBL1 = usr1 ...
Since it is found that the qualification of deletion (d) is registered here, YES is obtained and the process proceeds to S4. In the case of NO, there is no qualification for deleting the database 4, so the process ends (END).

A step S25 decides whether or not the record can be deleted.
This is based on the access right control information 8 extracted from the record of the deleted record ID, refers to the access right management table 9, and determines whether the user is qualified to delete the record (see FIG. 6). The decision of access rights will be described later). If yes, delete the record,
finish. If NO, the process ends without deleting.

As described above, in response to the deletion instruction, the access right management table 9 is referred to, and when it is determined that the database and the table for which the deletion instruction has been issued are qualified to be deleted, the contents of the record for which the deletion instruction is given are displayed. Then, the access right management table 9 is referred to based on the access right control information 8 in the access right control field 7 to determine whether or not the record has the delete right, and when the record is deleted, the record is deleted. As a result, deletion control can be performed for each user on a record-by-record basis.

FIG. 5 shows a flow chart of registration of the present invention. In FIG. 5, S31 gives an instruction to register a record. S32 accepts registration. At the time of accepting this registration, as shown in the figure: -database name-table name-user name-registration record information is received.

In step S33, it is determined whether or not the user is qualified to register in the database 4. This refers to the access right management table 9 to determine whether the user name of the database name or table name instructed to be registered is registered for update / registration (w). For example, the user name usr1 is as shown in FIG.
Referring to the access right management table 9 of DB1, TBL
For 1 qdw (search, delete, update / register) = usr
Since it is registered as 1 ..., it is found here that the qualification of update / registration (w) is registered, so YES
Then, the record is registered in S34. On the other hand, NO
In the case of, since there is no registration qualification of the database 4, the process ends (END).

As described above, in response to the registration instruction, the access right management table 9 is referred to, and when it is determined that the database and the table for which the registration instruction is issued are qualified to be registered, the record is registered. As a result, registration control can be performed for each user on a table-by-table basis. Once registered, it is possible to perform control such as search, update, and delete for each user in record units.

FIG. 6 shows an example of the access right to each record of usr1 derived from the access right control field and the access right management table of the present invention. This will be described in detail below. (1) Referring to the access right management table 9 of FIG. 1 for the user usr1, and since it was found that qdw (search, delete, update / register) for TBL1 of DB1, the process proceeds to the next step.

(2) Each record RD1 to R of the table TBL1 of the database DB1 from the database 4
For D4, access right control fields ACF1 and ACF
Access right control information is extracted from CF2 as follows.

Record ACF1 access right control information ACF2 access right control information RD1 1 abc RD2 0 abc RD3 0 xyz RD4 2 xyz (3) Referring to the access right management table 9 in FIG. 1, qualification of the access right of the user usr1 Take out. For example, in the case of the access right control information RD1 1 abc of the access right control information ACF2 of the record ACF1, since the access right control information of the ACF1 of the user usr1 is "1", the qualification at that time is "qdw". Turns out. Similarly, A of user usr1
Since it is the access right control information “abc” of CF2,
Then, the qualification at that time is found to be “qw”. When this is organized, it becomes the access right of the record ACF1 and the access right of the ACF2 access right RD1 qdw qw.

(4) When the AND operation of the access right "qdw" of the ACF1 and the access right "qw" of the ACF2 of the user usr1 obtained in (3) is performed, the access right "qw" is obtained. In summary, the access right of the record ACF1 is the access right of the ACF2 is the access right RD1 qdw qw qw, and the desired access right "qw" of usr1 is obtained.

(5) Similarly, records RD2 to RD
4, the access right of the user usr1 is as shown below. Access right of record ACF1 Access right of ACF2 Access right RD1 qdw qw qw RD2 qdw qw qw RD3 qdw --- RD4 qdw --- Access set by providing a plurality of access right control information fields ACF1, ACF2, etc. in the record. Corresponding to the right control information, it becomes possible to finely set the record access right qualification for each user for each record. Also, the access right control field AC
By arbitrarily changing the access right control information set in F1, ACF2, etc., it becomes possible to dynamically change the access right qualification for each user for each record (described later with reference to FIG. 7).

FIG. 7 shows usr1 according to usr2 of the present invention.
An example of granting an access right to RD3 of TBL1 will be described. In FIG. 7, S41 refers to the access right management table 9 and extracts the access right control information 8 for the RD3 of usr1. Here, the access right control information of record ACF1 and the access right control information RD3 0 xyz of ACF2 are extracted from FIG. Based on this, the access right management table 9
, The qualification of the access right of usr1 is illustrated (b-
1) Obtained as follows.

Access right of record ACF1 Access right of ACF2 Access right RD3 qdw--S42 refers to the access right management table 9 and usr
The access right control information 8 for RD3 of No. 2 is taken out. Here, similarly, the access right control information RD3 0 xyz of the access right control information ACF2 of the record ACF1 is extracted from FIG. Based on this, the access right management table 9
And the qualification of the access right of usr2 is illustrated (b-
2) Obtained as follows.

Access right of record ACF1 Access right of ACF2 Access right RD3 qdw qdw qdw S43 rewrites ACF2 of RD3 by usr2.
This is because, in S42, usr2 can be updated with the qualification “qdw” of the access right of RD3, so ACF2 of the RD3 concerned.
"Xyz" of is rewritten to "abc". This allows
The access right of usr1 in (b-1) will be changed as follows.

Access right of record ACF1 Access right of ACF2 Access right RD3 qdw qw qw By the above, a user who is qualified to update as an access right can arbitrarily rewrite the access right control information 8 in the access right control field 7 of the record. This makes it possible to dynamically change the user's access right qualification.

FIG. 8 is an explanatory view of a specific example of the present invention (part 1).
Indicates. This is a specific example in which the present invention is applied to a document management system. FIG. 8A shows an example of a table of the document management system. This is an example of the table TBL1 of the database 4 of FIG. Here, the section name is usr name, and there are the development section and the sales section. The ID corresponds to ACF1 and the approval corresponds to ACF2.

FIG. 8B shows an example of the access right management table of the document management system. Is described in the table TB of FIG. 8A of the database.
The search / update right of L1 is represented by * (everyone).

[0055] In the case of the access right control information ACF1 which is the access right control information “1”, the development section has the search / update right, all the search rights have the access right control information “2”, and The sales department has the search / update right, and everyone has the search right.

[0056] In the case of the access right control information ACF2 of approval, which is “not yet”, the section manager has the search / update right, the development section has the search right when ID = 1, and the ID = 2.
At that time, the sales department has it. On the other hand, in the case of the access right control information “approved” for approval, the section manager has the search / update right, and everyone has the search right.

FIG. 8C shows an example of a user definition file of the document management system. This is shown in FIG.
It is a file that defines the members of the development section, sales section, section manager, and * used in (b). Therefore, these members have the qualification of the access right determined by (a) and (b) of FIG. 8 corresponding to the corresponding development section, sales section, section manager, and *.

Next, as an example of FIG. 8, [1] Yamanaka of the Development Section indicates that the condition of the document type is “work report”.
A case will be described in which the results retrieved in step 3 are displayed on the terminal.

(1) The results of searching the database under the condition "work report" are RD2 and RD3 in FIG. 8 (a).
Is the following. Section name Document type ACF1 ACF2 RD2 Sales section Work report 2 Completed RD3 Development section Work report 1 Not established (2) Access right control field A for RD2 and RD3
The access right control information of CF1 and ACF2 is taken out, and the access right qualification is determined from the access right management table 9 of FIG. 8B.

Section name Document type ACF1 access right ACF2 access right RD2 Sales Division work report search / update right-Search right (all) Search right (all) RD3 Development Division work report search / update right Search right Search right (Everyone) -Therefore, the access right obtained by ANDing the access right of ACF1 and the access right of ACF2 is as follows.

Section name ACF1 access right ACF2 access right Access right RD2 Sales Division search / update right --- Search right (all) Search right (all) Search right (all) RD3 Development Division search / update right Search right Search right Search right (all) --- {1} (3) Therefore, since Tanaka of the Development Division has the search right for both RD2 and RD3, these RD2 and RD3 are displayed as search results.

[2] When Kamishima of the Sales Division displays the result of searching the condition “work report” of the document type on the terminal,
Since the access right can be determined as indicated by {1} by (1) and (2) of [1], only RD3 is displayed as the search result.

[3] Description will be made of a case where the development section manager Yamamoto discloses the information of RD3 to all. (1) Examine the qualification of the RD3 access right of the development section manager.

Section name Document type ACF1 ACF2 RD3 Development section Work report 1 Not yet available, so access right management table 9 in FIG.
The access right obtained by taking out the access right respectively by referring to and ANDing the two is as follows.

Section name ACF1 access right ACF2 access right Access right RD3 Section manager search / update right Search / update right Search / update right Search right (all)-{2} (2) Therefore, section manager Yamamoto's RD3 Since there is a search / update right, "not" in ACF2 of RD3 is updated to "done". As a result, the access rights are as follows.

Section name ACF1 access right ACF2 access right Access right RD3 Section manager Search / update right Search / update right Search / update right Search right (all) Search right (all) Search right (all) (3) All of RD3 have the search right and are made public.

FIG. 9 is a diagram for explaining a specific example of the present invention (part 2).
Indicates. This is an example in which the present invention is applied to a theater information search system. FIG. 9A shows the relationship between the information disclosure period and the screening period of the theater information retrieval system.

FIG. 9B shows an example of a table of the theater information search system. This is an example of the table TBL2 of the database 4 of FIG. Where the cinema name is us
There are r names, such as Shibuya A and Ikebukuro B. The screening start date corresponds to ACF1, and the screening end date corresponds to ACF2.

FIG. 9C shows an example of the access right management table of the theater information search system. Is described in the table TB of FIG. 9B of the database.
The L2 search / update right is owned by * (all users).

[0070] Is described on the start date of the screening, for example, "4
When "3/3" is entered and 4/3 <($ DATE (= current date) -14) is established (as indicated by the arrow in FIG. 9, before the information disclosure date), the search / update right is In the same manner, when 4/3 => ($ DATE (= current date) -14) is established (as indicated by the arrow in FIG. 9, the screening starts after the information disclosure date). During the 2 weeks before the date), search
The administrator has the update right, and the search right is all users (all movie theaters)
Represents what it has.

[0071] Is described on the end date of the screening, for example, "5
/ 7 ”, and when 5/7 <= $ DATE (= current date) is established (as shown by the arrow in FIG. 9, during the screening period), the administrator has the search / update right, Similarly, all users have the search right, and when 5/7> $ DATE is satisfied (as shown by the arrow in FIG. 9, after the information disclosure end date (screening end date)), the search / update right Indicates that the administrator has.

Next, as an example of FIG. 9, [1] A case will be described in which the user displays on the terminal the result of retrieval by the movie theater name “Shibuya A” on May 1.

(1) The results of searching the database under the condition "Shibuya A" are RD1 and RD3 in FIG. 9B. Movie Theater Title Start Date Start Date End RD1 Shibuya A Title A 4/3 5/7 RD3 Shibuya A Title B 5/8 6/28 (2) For the search period of RD1, use the arrow in (c) of FIG. As shown in (a) of FIG. 9, since it is a period from two weeks before the screening start period to the screening end date, it is from March 20th to May 7th, and the user's May 1st Is within this search period.

(3) The search period of RD3 is a period from two weeks before the screening start period to the screening end date, as shown in FIG. 9A using the arrow in FIG. 9C. Therefore, it will be from April 24th to June 28th, and the user's May 1st will be within this search period.

(4) Therefore, the search results of RD1 and RD3 are displayed on the screen of the terminal by (3) and (4). [2] A case will be described in which the user displays the search result on April 5 with the title “Title A” on the terminal.

(1) The result of searching the database under the condition "Title A" is RD1 and RD2 in FIG. 9B.
Is. Movie theater title Title start date End date RD1 Shibuya A Title A 4/3 5/7 RD2 Ikebukuro B Title A 4/24 5/21 (2) For the RD1 search period, click the arrow in (c) of FIG. As shown in (a) of FIG. 9, since it is the period from two weeks before the screening start period to the screening end date, it is from March 20 to May 7 and the user's April 5 Is within this search period.

(3) The RD2 search period is a period from two weeks before the screening start period to the screening end date, as shown in FIG. 9A using the arrow in FIG. 9C. Therefore, it will be from April 10th to May 21st, and the user's April 5th will be outside this search period (before the information disclosure date).

(4) Therefore, according to (3) and (4), only the search result of RD1 is displayed on the screen of the terminal.

[0079]

As described above, according to the present invention,
Since the access right management table 9 and the access right control field 7 for each record 6 are provided and the access control is performed for each user on a record basis with reference to this, the access control for each record and for each user ( Search, delete, update / register) can be performed. In addition, multiple access right control fields AC for each record
By providing F1, ACF2, etc., and determining the access right based on the logical product operation result of these, access control can be performed for each user in a fine-grained record unit.

[Brief description of drawings]

FIG. 1 is a principle configuration diagram of the present invention.

FIG. 2 is a flowchart of a search according to the present invention.

FIG. 3 is a flowchart of updating of the present invention.

FIG. 4 is a flowchart of deletion of the present invention.

FIG. 5 is a flowchart of registration of the present invention.

FIG. 6 is an example of an access right to each record of usr1 derived from the access right control field and the access right management table of the present invention.

FIG. 7 is an example of granting an access right to RD3 of TBL1 of usr1 by usr2 of the present invention.

FIG. 8 is a diagram (part 1) for explaining a specific example of the present invention.

FIG. 9 is a diagram (part 2) for explaining a specific example of the present invention.

[Explanation of symbols]

 1: Front end 2: Access device 21: Record access check processing 3: Database engine 31: Search function 32: Registration function 33: Update function 34: Delete function 4: Database 5: Table 6: Record 7: Access right control field 8 : Access right control information 9: Access right management table

 ─────────────────────────────────────────────────── ─── Continuation of the front page (72) Inventor Kazuko Ban No. 2-4, Fukami Nishi 4-chome, Yamato City, Kanagawa Prefecture PFU Yamato Factory Co., Ltd. (72) Inventor Hiroshi Yamaka 4-chome Fukami Nishi, Yamato City, Kanagawa Prefecture No. 49 Incorporated company PFU Yamato Factory (72) Inventor Ryoichi Tanaka 4-2 Fukami Nishi 4-chome, Yamato City, Kanagawa Prefecture Incorporated company PFU Yamato Factory (72) Inventor Ken Yamazaki 1 Dojima, Kita-ku, Osaka City, Osaka Prefecture Chome 5-17 PFU Kansai Software Co., Ltd. (72) Inventor Masatoshi Sagara 1-5-17 Dojima, Kita-ku, Osaka City, Osaka Prefecture PFU Kansai Software Co., Ltd. (72) Inventor Shoji Kose Yamato, Kanagawa Prefecture Fukami Nishi 4-chome No. 2-49 Co., Ltd. PFU Yamato Factory (72) Inventor Yuichi Fujita Kanagawa Fukami Nishi 4-chome, Yamato-shi, Fukushima, Ltd. PFU Yamato Factory Co., Ltd. (72) Inventor Noboru Nakazawa 4-4-2 Fukami-nishi 4-chome, Yamato City, Kanagawa Prefecture

Claims (3)

[Claims] 1. A database control device for controlling access to each record of a database, an access right control field which is provided for each record (6) of a database table (5) and in which access right control information (8) is arbitrarily set. (7) and the qualification of the user's access right for each database table (5), and the qualification of the access right for each user to the access right control information (8) set in the above access right control field (7) An access right management table (9) for pre-registering the above, and performing access right control for each user on a record (6) basis. 2. A plurality of access right control fields (7) of the record (6) are provided, and access right control information (8) for each of the plurality of access right control fields (7) is provided in the access right management table (9). ), Each qualification for each user is registered, and the access right as a result of the logical product operation of these registered qualifications is obtained, and the access right control for each user is performed for each record (6). The database control device according to claim 1. 3. The update qualification of this user is registered in a corresponding table (5) in the access right management table (9) in response to a change instruction of the access right control field (7) from the user, and When it is registered corresponding to the access right control information (8) of the corresponding access right control field (7) (when there are multiple registrations, there is an update as the access right of the result of the AND operation) The database control device according to claim 1 or 2, wherein the access right control information (8) of the corresponding access right control field (7) of the record (6) is changed.