JP2004046733A - Device for integrated management of attribute information - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To integrally manage attribute information which are individually managed in a database and a directory. <P>SOLUTION: A conversion program 20 inputs change source changing information and change destination writing destination information as a parameter. Based on the above information and information stored in a conversion table 70, attribute information which is specified by the change source changing information managed in an attribute DB 1 and an attribute directory 3 is changed through the use of a DB system master conversion engine 15, and a directory conversion engine 14. <P>COPYRIGHT: (C)2004,JPO

Description

で示される。
【００３１】また、ディレクトリの場合には、
変更前ディレクトリ　　名前ＩＤ　００１１　山田太郎−−−職位プロパティ課長補佐
変更後ディレクトリ　　名前ＩＤ　００１１　山田太郎−−−職位プロパティ課長
で示される。
【００３２】
この場合は、当該ＤＢまたは当該ディレクトリから、後述するステップＳ３で読み込む情報を基に自動生成する。すなわち、上記ＤＢ及び上記ディレクトリの例の場合には、変更前情報と変更後情報の差分計算を行い、
００１１　山田太郎　変更　職位　変更前　課長補佐　変更後　課長
の情報を自動作成する。
【００３３】
続いて、「変換テーブル読み込み」で、図４（ａ）に示す変換テーブル７０を読み込む（ステップＳ２）。そして、「変換先及び変換先の構造情報読込」で、変換テーブル７０から、「変換先種別７０ｂ」、「変換先名称７０ｃ」及び「ＤＢ及びディレクトリ構造情報７０ｄ」を読み込む（ステップＳ３）。
【００３４】
次に、「変換先書込先情報読込（一時領域など）」で、パラメータとして指定された変換先書込先情報を読み込み、この情報を基に、ステップＳ１で読み込んだ変換元変更情報７１の書き込み領域を特定する（ステップＳ４）。これは、属性情報は、情報の入替え時期が決まっている場合が多く、それ以前は、一時領域や決められた領域書き込んでおいて、指定した時期に運用する（前記変換先書込先情報で指定される領域に、実際に書き込む））ことが多いからである。
【００３５】
続いて、「キーの追加または削除」が有るか判断して、キーの追加または削除」が有る場合には、名前ＩＤをキーにしている場合は、当人が転出などでいなくなる場合または新規に転入する場合などは、ＤＢのレコード追加・削除、ディレクトリの属性追加を行う（ステップＳ６）。
【００３６】
ステップＳ５でキーの追加または削除が無いと判断された場合またはステップＳ６の処理の後に、「変換元変更情報及び構造情報から該当情報を変換先書込先に書込」で、ステップＳ１で読み込んだ変換元変更情報を基に、ステップＳ３で読み込んだ構造情報及びステップＳ４で読み込んだ変換先書き込み先情報を利用して、ステップＳ２で読み込んだ「変換先種別７０ｂ」（図４（ａ）参照）に従い、変換先がＤＢの場合は、ディレクトリ変換エンジン１４によりＬＤＡＰを用いて当該ディレクトリ（属性ディレクトリ３）の当該情報をアクセスし、変換先がＤＢの場合は、ＤＢ系マスタ変換エンジン１５によりＳＱＬを用いて当該ＤＢ（属性ＤＢ１）の当該情報をアクセスし、それらの当該情報を指定された変更後情報に変更する（ステップＳ７）。尚、このステップＳ７においては、必要に応じて、ディレクトリ変換エンジン１４とＤＢ系マスタ変換エンジン１５の両者が実行される。
【００３７】
そして、最後に、「変換エンジンＩＤ読込み特殊処理を実行」で、ステップＳ２で読み込んだ変換ＩＤ７０ａ（図４（ａ）参照）で指定された特殊処理がある場合には当該特殊処理を実行する（ステップＳ８）。前述したように、特殊処理は、変換先のＤＢの構造が正規化されていない場合などのように、１対Ｎの変換が必要な場合に行われる。したがって、変換元と変換先が１対１の場合には、特殊処理は不要である。
【００３８】
以上のようにして、ステップＳ７とＳ８の処理により、ディレクトリとＤＢの属性情報（両者に共通な属性情報）の一括変換がなされる。
この一括変換処理の具体例を、図４（ｂ）のマスタＡから、ディレクトリＡとマスタＢに一括変換する場合を取り上げて説明する。
【００３９】
属性Ａを職位とした場合、マスタＡの属性Ａは「課長」、ディレクトリＡとマスタＢの属性Ａは「課長補佐」になっているものとする。
この場合、変更前のマスタＡの属性Ａは「課長補佐」になっているので、
「００１１山田太郎　変更　職位　変更前　課長補佐　変更後　課長」
という情報を自動作成して、ディレクトリ変換エンジン１４でディレクトリＡの属性Ａを「課長」に、ＤＢ系マスタ変換エンジン１５でマスタＢの属性Ａを「課長」に書き換える。
【００４０】
尚、属性ＤＢ１の属性マスタＤＢ（図２参照）で管理されている世代情報を、ディレクトリ（属性ディレクトリ３）を参照しているサーバで参照したい場合には、予め、旧世代用の書き込み領域（変換先書込先）を用意して、ステップＳ１で読み込む変更元変更情報７１を入力元、ステップＳ４で読み込む変換先書込先を出力先として、変換プログラム２０を実行することにより、ディレクトリに上記世代情報が格納される。
【００４１】
本発明は、下記の属性管理等に適用できる。
１）　官庁における職員認証での属性管理
２）　民間企業における社員認証での社員の属性管理
３）　電子申請におけるＰＫＩ電子署名の認証対象者の属性管理
４）　電子入札におけるＰＫＩ電子署名の認証対象者の属性管理
５）　電子カルテにおけるＰＫＩ電子署名の認証対象者及びアクセス者の属性管
理
６）　電子商取引における参加企業または個人の属性管理
また、本実施形態の変換プログラム２０及び拡張メタディレクトリ７は、各種規格のＣＤ，各種規格のＤＶＤ，フレキシブルディスク、光ディスク、光磁気ディスク、メモリーカード、ＲＯＭカード等の可搬性の記録媒体により頒布することも可能である。また、有線または無線の通信を介して、頒布することも可能である。また、変換プログラム２０と拡張メタディレクトリ７は、別個の可搬記録媒体により頒布されてもよい。そして、このようにして頒布された変換プログラム２０及び拡張メタディレクトリ７は、コンピュータにより実行されて、上述した本実施形態の各機能をコンピュータに実行させる。
【００４２】
尚、本発明が適用されるデータベースは、リレーショナルデータベースに限定されず、本発明は、例えば、オブジェクト指向データベースなどの他の形態のデータベースで管理される属性情報の管理にも適用可能である。
【００４３】
【発明の効果】
以上説明したように、本発明によれば、ディレクトリとデータベースを統合して一括管理する拡張メタディレクトリに、該ディレクトリの情報と該データベースの情報を統合変換するための変換ルールを格納し、ディレクトリアクセス用の変換エンジンとデータベースアクセス用の変換エンジンにより、変更情報を、一括して当該ディレクトリと当該データベースに書き込むことにより、ディレクトリの管理する属性情報とデータベースの管理する属性情報の等価を図るので、ディレクトリとデータベースに共通する属性情報を、容易、高速、かつ確実に一括変更できる。また、既存のシステムに変更を加えることなく、ディレクトリの属性情報とデータベースの属性情報を統合管理でき、改造コストの削減を図ることができる。
【図面の簡単な説明】
【図１】本発明の実施形態を適用した電子署名システムの構成を示す図である。
【図２】図１の実施形態のソフトウェア構成を示す図である。
【図３】変更元変更情報のデータ構造を示す図である。
【図４】変換テーブルの構成を説明する図である。
【図５】変換プログラムの処理の流れを説明する図である。
【図６】従来の電子署名システムの構成を示す図である。
【符号の説明】
３　　　属性ディレクトリ
６　　　既存マスタ
７　　　拡張メタディレクトリ
１４　　ディレクトリ変換エンジン
１５　　ＤＢ系マスタ変換エンジン
２０　　変換プログラム
７０　　変換テーブル
７０ａ　　変換ＩＤ
７０ｂ　　変換先種別
７０ｃ　　変換先名称
７０ｄ　　ＤＢ及びディレクトリ構造情報
７０ｅ　　変換エンジンＩＤ
７１　　変更元変更情報
７２　　ＤＢ及びディレクトリ構造情報
７２ａ　　マスタＡ構造
７２ｂ　　ディレクトリＡ構造
７２ｃ　　マスタＢ構造[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to an attribute information management technology for centrally managing attribute information such as a name, an affiliation, and a position, and is particularly suitable for access control of an electronic authentication system.
[0002]
[Prior art]
For example, in an electronic authentication system, attribute information such as a name, an organization, and a position is used as determination information for controlling an access right. In addition, attribute information is used in staff authentication in government offices, employee authentication in private companies, authentication of PKI (Public Key Infrastructure) electronic signatures in electronic applications, authentication of PKI electronic signatures in electronic medical records, and the like.
[0003]
FIG. 6 is a diagram showing a configuration of a conventional electronic authentication system.
In the figure, an authentication server 102 of an electronic authentication system 100 manages electronic authentication data by an attribute DB (attribute database) 101, and a client 104 requires an electronic certificate from the authentication server 102 to access the server 103. You need to get Further, the authentication server 206 of the electronic authentication system 200 manages the electronic authentication data by using the attribute directory 201, and the client 208 needs to acquire the electronic certificate from the authentication server 206 in order to access the server 207. Yes. The existing master 301 is a file that manages attribute information, like the attribute DB 101 and the attribute directory 201.
[0004]
In the conventional system shown in FIG. 1, attribute information is individually managed by an attribute DB (attribute database) 101, an attribute directory 201, an existing master 301, and the like. Management) was not centralized. When integrating two of these three types of management devices, it is necessary to take measures such as matching one to the other or constructing a new management device. By the way, with regard to directories, there is a concept of a metadirectory for integrating directories into one, but this concept corresponds only to directories, and does not correspond to a DB (database). In addition, this is not specific to electronic authentication but general-purpose, and individual use of programming was required to actually use the electronic authentication system.
[0005]
[Problems to be solved by the invention]
When attribute information is managed by individual devices as in a conventional system, for example, every time an organizational change or personnel change occurs, a great deal of effort is required to manage the individual attribute DB 101 or attribute directory 201. Need to be changed, and this is costly, and the time required for the change and the occurrence of mistakes due to the change work pose problems. Further, in order to integrate the respective attribute directories 201 or the attribute DBs 101, the existing system needs to be remodeled, and a problem arises as to whether the remodeling is possible. In addition, the technology of the meta directory cannot be applied to the DB, and there is a problem that the system of the attribute DB 101 cannot be integrated.
[0006]
According to the present invention, when the attribute information individually managed in the DB, the directory, and the existing master is changed, the attribute information managed by the DB, the directory, and the existing master can be easily, quickly, and reliably. It is possible to make a batch change and realize this change work without changing the existing system, thereby realizing a unified integrated management of attribute information managed in each DB and directory. The aim is to reduce remodeling costs.
[0007]
[Means for Solving the Problems]
An attribute information integrated management device of the present invention includes a management unit storing conversion rules for integrally managing attribute information individually managed in a database and a directory, and a conversion rule stored in the management unit. A conversion unit for changing attribute information managed by the database or the directory with reference to the database or the directory.
[0008]
In the attribute information integrated management device having the above configuration, for example, the management unit has a conversion table for storing the conversion rule, and the conversion table identifies a conversion destination database or directory as information on the conversion rule. And the conversion means may be configured to access the conversion destination database or directory based on the identification information and the structure information. .
[0009]
In the attribute information integrated management device having the above-mentioned configuration, for example, the conversion table further stores identification information of a special process required in each database or each directory as information on the conversion rule, for example. May be configured to execute a special process specified by the identification information on the database or the directory.
[0010]
In the attribute information integrated management device having the above configuration, for example, in the conversion table, information common to databases and directories in a symmetric range is defined as a unified key, and the conversion unit performs the conversion based on the key. It may be configured to add or delete attribute information of a symmetric range database or the directory.
[0011]
The attribute information integrated management method of the present invention stores a conversion rule for integrated management of attribute information individually managed in a database and a directory, and refers to the conversion rule to be managed in the database or the directory. Change the attribute information.
[0012]
The program of the present invention has a function of storing a conversion rule for integrally managing attribute information individually managed in a database and a directory, and is managed in the database or the directory with reference to the conversion rule. Causes a computer to execute a function of changing attribute information.
[0013]
The present invention provides a conversion rule for integrally managing attribute information individually managed in a database and a directory, and changes attribute information managed in the database or the directory by referring to the conversion rule. To do. This makes it possible to change the attribute information managed separately for the database and the directory, respectively, and realize integrated management of the database and the directory.
[0014]
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
FIG. 1 is a diagram illustrating a system configuration of an electronic authentication system to which an attribute information management device according to an embodiment of the present invention is applied.
[0015]
In the figure, the authentication server 2 manages access control information of a server (application server) 9 based on information managed by an attribute DB (attribute database) 1. The authentication server 5 manages access control information of the server 9 based on information managed by the attribute directory 3. The extended metadirectory 7 integrates and manages the attribute DB1, the attribute directory 3, and the existing master 6 according to conversion rules. The conversion rule is described in, for example, a table (conversion table).
[0016]
When accessing the server 9, the client 8 acquires the access authority level from the management information of the attribute directory 3 via the authentication server 5, and transfers the access authority level to the server 9 to manage the server 9. Access within the range permitted by the current access authority level is possible.
[0017]
Further, since the information of the attribute DB 1, the attribute directory 3, and the existing master 6 are equivalent by the extended metadirectory 7, even if the client 8 is authenticated by the authentication server 2, The result is the same as However, if the authentication server 2 manages the unique attribute information and sets the access authority level independently, the above result does not apply.
[0018]
As can be seen from a comparison between FIG. 1 and FIG. 6, in this embodiment, an extended metadirectory 7 is added to the conventional system of FIG. 6, and this extended metadirectory 7 stores the attribute DB1, the attribute directory 3, and the existing master 6. It is configured to perform integrated management.
[0019]
FIG. 2 is a software configuration diagram of the system of FIG.
The attribute directory 3 manages attribute master information, certificates and revocation lists in the case of PKI (Public Key Infrastructure) authentication. The attribute DB1 manages personnel information in the personnel master and information such as affiliation and post in the attribute master. In some cases, the attribute master manages generation information that is past attribute information.
[0020]
The extended metadirectory 7 has a conversion table 70 storing conversion rules for updating the contents of the attribute directory 3 and the attribute DB1. The conversion program 20 includes a directory conversion engine 14 and a DB system master conversion engine 15, and starts these engines. The directory conversion engine 14 accesses the information of the attribute directory 3 by using LAPD (Light Weight Directory Access Protocol). The DB system master conversion engine 15 accesses the information of the attribute DB1 using SQL (Structure Query Language).
[0021]
The attribute information management device according to the present embodiment includes an extended metadirectory 7 and a conversion program 20 (including a directory conversion engine 14 and a DB system master conversion engine 15).
[0022]
Since the authentication server 2, the application server 9, and the client 8 are not components of the embodiment of the present invention, the description of the software configuration of the authentication server 2, the application server 9 will be omitted. The client 8 includes a PKI-compatible Web browser, a master management tool corresponding to a metadirectory and a PMI (Privilege Management Infrastructure) function, and an IC card reader on which a GPKI (Government PKI) -compatible IC card is mounted.
[0023]
FIG. 3 is a diagram showing contents of conversion source change information which is an input value (parameter) of the conversion program 20.
The conversion source change information 71 shown in FIG. 7 includes change attribute items for specifying which attribute information is to be changed, information before change (information before change) and information after change (information after change) of the attribute information to be changed. Are listed, and are input to the conversion program 20. The conversion source change information 71 is input to the conversion program 20 when the pre-change information and the post-change information of a CSV format, an Excel table, a DB, or a directory are specified, for example.
[0024]
Note that the DB information (information of the attribute DB1) and the directory information (information of the attribute directory 3) may be directly used as the conversion source change information 71 in some cases.
FIG. 4 is a diagram showing a configuration of the conversion table 70.
[0025]
FIG. 7A is a diagram showing items constituting a conversion rule stored in the conversion table 70.
The conversion table 70 includes five items: “conversion ID 70a”, “conversion destination type 70b (DB or directory)”, “conversion destination name 70c”, “DB and directory structure information 70d”, and “conversion engine ID 70e”. ing.
[0026]
The conversion ID 70a is set for each DB or each directory, and is an identifier used for identifying the conversion. The conversion destination type 70b is information indicating whether the conversion destination is a DB or a directory. The conversion destination name 70c is the name of the conversion destination DB or directory. The DB and directory structure information 70d is information indicating the database structure of the conversion destination attribute DB1 and the directory structure of the conversion destination attribute directory 3. The conversion engine ID 70e is an identifier used for identifying a special process when performing the special process. The special processing is necessary, for example, when the structure of the conversion destination DB has not been normalized. In such a case, conversion of 1 to N (N is a natural number of 2 or more) instead of 1 to 1 is required. Since the conversion table 70 is based on one-to-one conversion, if one-to-N conversion is required, it is written in N places by special processing.
[0027]
FIG. 2B is a diagram showing an example of “DB and directory structure information 70 d” stored in the conversion table 70. FIG. 2B shows the respective structure information of masters A (personnel masters) and B (attribute masters) which are master DBs belonging to the attribute DB 1 and directory A which is an attribute master of the attribute directory 3. . The master A is, for example, a personnel master, and its record is composed of three fields of a key and attributes A and B. The master B is, for example, an attribute master, and its record is composed of a key and four fields of attributes A, B, and D. The objects in the directory A are composed of keys and attributes A, B, and C. If the “conversion ID 70a” of the conversion table 70 is the ID of the attribute DB1, the “DB and directory structure information 70d” of the conversion table 70 include the master A (personnel master) and the master B ( Attribute master) structure information is stored.
[0028]
In the present embodiment, unique information common to the DB (attribute DB1) and the directory (attribute directory 3) in the symmetric range is defined as a key. In the example of FIG. 3B, the name ID is a key. The attribute information includes information common to all DBs and directories and information specific to each DB or directory.
[0029]
FIG. 5 is a flowchart showing the flow of the processing of the conversion program 20.
The conversion program 20 is automatically or manually activated for each conversion ID 70a (see FIG. 4A) in a state where the conversion source change information 71 and the conversion destination writing destination information are specified as parameters.
[0030]
First, when a personnel change or an organization change occurs in "read conversion information", the change source change information 71 shown in FIG. 3 is read (step S1). The change information may be indicated by a data string or in a format stored in a DB or a directory. For example, in the case of a data string, it is indicated in CSV format of “0011, Taro Yamada, position, assistant section manager, section manager”. In the case of DB,

Indicated by
In the case of a directory,
Directory name before change Name ID 0011 Taro Yamada --- Assistant to post-property section manager Post-change directory name ID 0011 Taro Yamada --- Represented by post-property section manager.
[0032]
In this case, it is automatically generated from the DB or the directory based on information read in step S3 described later. That is, in the case of the DB and the directory, a difference between the pre-change information and the post-change information is calculated,
0011 Taro Yamada Change Position Before change Assistant to section manager After change Automatically create section manager information.
[0033]
Subsequently, the conversion table 70 shown in FIG. 4A is read by "read conversion table" (step S2). Then, in "Read conversion destination and structure information of conversion destination", "Conversion destination type 70b", "Conversion destination name 70c", and "DB and directory structure information 70d" are read from conversion table 70 (step S3).
[0034]
Next, in "Read conversion destination writing information (temporary area, etc.)", the conversion destination writing information specified as a parameter is read, and based on this information, the conversion source change information 71 read in step S1 is read. The writing area is specified (Step S4). This is because, in many cases, the replacement time of the attribute information is determined, and before that, a temporary area or a predetermined area is written and operated at the specified time (the conversion destination writing destination information is used for the attribute information). This is because writing is actually performed in the designated area)).
[0035]
Next, it is determined whether there is "addition or deletion of a key", and if there is "addition or deletion of a key", if the name ID is used as a key, if the person is not moved out or a new person is added. For example, when the data is transferred to the database, the record addition / deletion of the DB and the attribute addition of the directory are performed (step S6).
[0036]
When it is determined in step S5 that there is no key addition or deletion, or after the processing in step S6, "write the corresponding information from the conversion source change information and the structure information to the conversion destination writing destination" is read in step S1. The “conversion destination type 70b” read in step S2 using the structural information read in step S3 and the conversion destination write destination information read in step S4 based on the conversion source change information (see FIG. 4A). ), If the conversion destination is a DB, the directory conversion engine 14 accesses the information of the directory (attribute directory 3) using LDAP, and if the conversion destination is a DB, the DB system master conversion engine 15 uses the SQL. To access the relevant information of the DB (attribute DB1) and change the relevant information to the specified post-change information (step Flop S7). In step S7, both the directory conversion engine 14 and the DB system master conversion engine 15 are executed as necessary.
[0037]
Finally, if there is a special process designated by the conversion ID 70a (see FIG. 4A) read in step S2 in "Execute conversion engine ID reading special process", the special process is executed ( Step S8). As described above, special processing is performed when one-to-N conversion is required, such as when the structure of the conversion destination DB is not normalized. Therefore, when the conversion source and the conversion destination are one-to-one, special processing is unnecessary.
[0038]
As described above, by the processes of steps S7 and S8, the attribute information of the directory and the DB (the attribute information common to both) is converted collectively.
A specific example of the batch conversion process will be described with reference to the case of batch conversion from master A to directory A and master B in FIG.
[0039]
When the attribute A is the position, the attribute A of the master A is "section manager", and the attribute A of the directory A and the master B is "assistant section manager".
In this case, since the attribute A of the master A before the change is “assistant section manager”,
"0011 Taro Yamada Change Position Position Before Change Assistant Manager After Change Manager"
Is automatically created, and the directory conversion engine 14 rewrites the attribute A of the directory A to “section manager” and the DB system master conversion engine 15 rewrites the attribute A of the master B to “section manager”.
[0040]
When the generation information managed by the attribute master DB (see FIG. 2) of the attribute DB1 is to be referred to by the server that is referencing the directory (attribute directory 3), the write area (for the old generation) must be specified in advance. A conversion destination write destination) is prepared, and the conversion source change information 71 read in step S1 is set as an input source, and the conversion destination write destination read in step S4 is set as an output destination. The generation information is stored.
[0041]
The present invention is applicable to the following attribute management and the like.
1) Attribute management by staff authentication in government offices 2) Attribute management of employees in private company employee authentication 3) Attribute management of PKI electronic signature authentication target in electronic application 4) PKI electronic signature authentication target in electronic bidding 5) Attribute management of PKI electronic signature authentication target and accessor in electronic medical records 6) Attribute management of participating companies or individuals in electronic commerce Also, the conversion program 20 and extended metadirectory 7 of the present embodiment It can also be distributed on portable recording media such as standard CDs, various standard DVDs, flexible disks, optical disks, magneto-optical disks, memory cards, and ROM cards. It is also possible to distribute via wired or wireless communication. Further, the conversion program 20 and the extended metadirectory 7 may be distributed on separate portable recording media. The conversion program 20 and the extended metadirectory 7 thus distributed are executed by a computer, and cause the computer to execute the functions of the present embodiment described above.
[0042]
Note that the database to which the present invention is applied is not limited to a relational database, and the present invention is also applicable to management of attribute information managed by another type of database such as an object-oriented database.
[0043]
【The invention's effect】
As described above, according to the present invention, a conversion rule for integrating and converting the information of the directory and the information of the database is stored in the extended metadirectory for integrating and managing the directory and the database, and The conversion engine for database and the conversion engine for database access write change information collectively to the directory and the database, so that the attribute information managed by the directory is equivalent to the attribute information managed by the database. , And attribute information common to databases can be easily, quickly, and reliably changed in a batch. Further, it is possible to integrally manage the attribute information of the directory and the attribute information of the database without changing the existing system, and it is possible to reduce the remodeling cost.
[Brief description of the drawings]
FIG. 1 is a diagram showing a configuration of an electronic signature system to which an embodiment of the present invention is applied.
FIG. 2 is a diagram illustrating a software configuration of the embodiment of FIG. 1;
FIG. 3 is a diagram showing a data structure of change source change information.
FIG. 4 is a diagram illustrating a configuration of a conversion table.
FIG. 5 is a diagram illustrating a flow of processing of a conversion program.
FIG. 6 is a diagram showing a configuration of a conventional electronic signature system.
[Explanation of symbols]
3 Attribute directory 6 Existing master 7 Extended metadirectory 14 Directory conversion engine 15 DB system master conversion engine 20 Conversion program 70 Conversion table 70a Conversion ID
70b Conversion destination type 70c Conversion destination name 70d DB and directory structure information 70e Conversion engine ID
71 Change source change information 72 DB and directory structure information 72a Master A structure 72b Directory A structure 72c Master B structure

Claims (6)

Management means for storing conversion rules for integrated management of attribute information individually managed in the database and the directory;
A conversion unit for changing attribute information managed in the database or the directory with reference to a conversion rule stored in the management unit;
An attribute information integrated management device comprising: The management unit has a conversion table that stores the conversion rule,
The conversion table includes information on the conversion rule,
Stores information for identifying the conversion destination database or directory, and the structure information of each database and each directory,
2. The attribute information integrated management device according to claim 1, wherein the conversion unit accesses the conversion destination database or directory based on the identification information and the structure information. The conversion table, as the information on the conversion rule, further stores identification information of special processing required in each database or each directory,
The attribute information integrated management device according to claim 2, wherein the conversion means executes a special process specified by the identification information on the database or the directory. In the conversion table, information common to databases and directories in a symmetric range is defined as a centralized key,
3. The attribute information integrated management device according to claim 2, wherein the conversion unit adds or deletes attribute information of the database of the symmetric range or the directory based on the key. Stores conversion rules for integrated management of attribute information individually managed in databases and directories,
An attribute information integrated management method, wherein attribute information managed in the database or the directory is changed with reference to the conversion rule. A function to store conversion rules for integrated management of attribute information individually managed in the database and the directory,
With reference to the conversion rule, a function of changing the attribute information managed in the database or the directory,
A program to be executed by a computer.

Images