JP2012018579A - Information retrieval device, information retrieval method and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an information retrieval device, an information retrieval method and a program capable of performing information retrieval for any data file in the same way even when how to hold information varies according to each data file.SOLUTION: A virtual DB is created from a high-capacity storage device 5 storing a career file 51 and an additional post history file dependent on the career file 51, a data table for retrieval in which records having the same date in the virtual DB are grouped together into one record is created, and data corresponding to an input retrieval condition is retrieved from the data table for retrieval.

Description

  The present invention relates to an information search apparatus, an information search method, and a program for storing data for each date when an event occurs and searching for necessary data from a plurality of stored data.

  In companies and the like, it is common to store employee personal information in a database and manage it with a computer. Patent Document 1 discloses a history data processing apparatus capable of effectively searching and extracting necessary data from accumulated data. The device described in Patent Document 1 stores data for each date when an event occurs, and when searching and extracting from a plurality of stored data, not only the date when the event occurred, but also any date as a reference, The target data can be searched.

Patent No. 2860063

  However, in recent years, personal information tends to become more complex, and multiple events can occur on the same day, so the structure of the database, such as the creation of multiple data files for managing the data to be stored, etc. Is getting complicated. Such a case where a plurality of events occur on the same day is not considered in the above-described conventional technology, and a search based on an arbitrary day cannot be performed. In order to solve such a problem, it is conceivable to increase the record length so that all events can be stored in one record. However, the number of events occurring by a customer cannot be fixed, and it is not realistic to prepare an infinitely long record so that any number can be accommodated in consideration of the database load. That is, if a table in which long records are defined regardless of the amount of data is prepared, the capacity of the database is wasted and a wasteful load is generated when searching. For this reason, in the case of a data structure in which the number of data is not known, it is normal to correspond not by the record length but by the number of records. That is, if a record is added every time an event occurs, the database can be used effectively. However, if the number of records corresponds to multiple events, there will be multiple records with the same date. In the above prior art, since the event of any date is searched from the date stored in the record being processed and the date stored in the next record, if there is a record of the same date, Cannot search normally.

  The present invention has been made in view of such circumstances, and an object of the present invention is to provide an information search apparatus capable of performing an efficient information search based on an arbitrary date even when a plurality of records exist on the same day, It is to provide an information search method and program.

  An information search device disclosed in the present application includes a first history table that stores an individual history and a date in association with each other, and stores a history that corresponds to the date and that is different from the history. And a history specifying unit for specifying a history having the same date accumulated in the first and second history tables, and a plurality of histories specified by the history specifying unit, the number of histories is counted and a maximum value is specified. Generating a third history table having a maximum value specifying unit, a cell for storing a history of the number of items according to the maximum value specified by the maximum value specifying unit, and a cell for storing a date in association with each other, A table creation unit for storing the history accumulated in the first and second history tables for each date in the third history table, a reception unit for receiving a search condition including a search item, and a search condition received by the reception unit In the search item included Accordingly, a first extraction unit that extracts a history corresponding to the corresponding search item from the third history table, obtains the history date, and calculates the history period based on the next history date. A history period calculation unit; a second extraction unit that identifies a history that satisfies the search condition based on the history extracted from the third history table by the first extraction unit and the period calculated by the history period calculation unit; With.

  The information search apparatus disclosed in the present application is efficient based on an arbitrary date using the third history table, even if the database structure has no limit on the number of histories that occur on the same day as in the second history table. Therefore, the user can search the target history information without paying particular attention to the storage mode. In addition, since the history is searched from the third history table, it is not necessary to construct a new search method in the information search apparatus, and it is possible to avoid an excessive search time.

It is a mimetic diagram of a personnel management device concerning an embodiment. It is a block diagram which shows the hardware constitutions of the personnel management apparatus which concerns on embodiment. It is a schematic diagram for demonstrating a part of data file which a personal information file manages. It is a block diagram which shows typically the function implement | achieved with a personnel management apparatus. It is a figure which shows a career file typically. It is a figure which shows a concurrent job history file typically. It is a figure which shows a seconding history file typically. It is a schematic diagram which shows an example of the selection screen which displays the list of the data files of search object. It is a figure which shows a connection definition file typically. It is a figure which shows typically the virtual DB created. It is a schematic diagram which shows the data table for search. It is a flowchart which shows the procedure of a data search process. It is a flowchart which shows the process sequence of a search execution process. It is a flowchart which shows the procedure of a data restoration search process. It is a schematic diagram for demonstrating the search / extraction method of an employee. It is a schematic diagram for demonstrating the search / extraction method of an employee. It is a schematic diagram of another example of the personnel management apparatus which concerns on embodiment.

  DESCRIPTION OF EXEMPLARY EMBODIMENTS Preferred embodiments of an information search device, an information search method, and a program according to the present invention will be described below with reference to the drawings. In the embodiment described below, the information search device according to the present invention is a personnel management device that manages personnel information in a company, and a general personal computer (hereinafter referred to as a personal computer) will be described as an example. The information search device according to the present invention is a computer, a mobile phone, or a personal digital assistant (PDA) that manages personal information in hospitals or schools, or article information in logistics in addition to personnel information in a company. May be.

  The personnel management apparatus according to the present embodiment stores a data file for managing the employee's career, and the data file includes data including the date of change each time an employee's personnel change is issued. Information is added for each employee who was transferred. Using this data file, the HR management device, for example, inputs an instruction to search for “employee who was enrolled in the head office sales” for example, what year, what month, what day, You can search for multiple employees. In addition, the HR management device adds up the number of days that the employee who has searched stays in the head office sales until a certain reference date even if the employee to be searched is moved from head office sales → branch A → head office sales → branch B Even if the search condition is “an employee who has been enrolled in head office sales for more than one year”, the corresponding employee can be searched.

  FIG. 1 is a schematic diagram of a personnel management apparatus according to the embodiment, and FIG. 2 is a block diagram illustrating a hardware configuration of the personnel management apparatus according to the embodiment. A personnel management device 1 according to the present embodiment includes a central processing unit (CPU) 2, a read only memory (ROM) 3, a random access memory (RAM) 4, a mass storage device 5, an input unit (accepting unit) 6, and An output unit 7 and the like are provided.

  The CPU 2 reads out and executes a program stored in advance in the ROM 3 or the large-capacity storage device 5 in the RAM 4 and controls the operation of each hardware unit described above. The ROM 3 stores in advance a program 3a for causing the personnel management apparatus 1 to perform necessary operations. The program 3a is installed in the mass storage device 5 by a recording medium 9 such as a Compact Disc-ROM (CD-ROM), a Digital Versatile Disc-ROM (DVD-ROM), or a Magneto-Optical disk (MO). Alternatively, it may be downloaded from a network and used.

  The RAM 4 is, for example, a static RAM (SRAM), a dynamic RAM (DRAM), a flash memory, or the like. The RAM 4 temporarily stores various data generated when the CPU 2 executes the program. The input unit 6 is a keyboard and a mouse for inputting data such as employee information and a search condition for searching for necessary data, and the output unit 7 is a monitor for displaying a search result. The output unit 7 may be a printer that prints search results.

  The mass storage device 5 is, for example, a hard disk drive, and stores various necessary data and various necessary programs. Specifically, the large-capacity storage device 5 stores a personal information file 50. The personal information file 50 is a file for managing employee information, and manages information for each employee in the company. The personal information file 50 manages a plurality of data files such as a career file 51 and a work / work history file 52 in which employee information is further detailed.

  FIG. 3 is a schematic diagram for explaining a part of a data file managed by the personal information file 50.

  The career file 51 (first history table) is a data file for managing the affiliation, job title, and the like in the employee's duties, and is stored so that it can be uniquely identified by the personal number and the change date. Each time a personnel change is issued, information including the date of change is additionally created in the history file 51 for each employee. The career file 51 starts the personal number assigned to each employee, the date of transfer, the date when the second employee is transferred (the date on which the second employee is dispatched), and the concurrent job (duties other than the main duties) The information of the date (date of concurrent appointment) is stored. The career file 51 and the seconding history file are subordinate to the career file 51.

  The concurrent job history file (second history table) is a data file for managing a working shop or the like in the concurrent job history when the concurrent job is issued. In the concurrent job history file, information such as the employee's office in the concurrent job is stored in association with the personal number of the career file 51 and the date when the concurrent job is issued. Further, the concurrent job history file stores information such as the dispatching date when the employee corresponding to the personal number is seconded. The seconding history file (second history table) is a data file for managing the seconding history when a seconding is issued in the main duty or concurrently. The second transfer history file is a data file in which information such as the second transfer destination and the second transfer post is stored in association with the personal number and the second dispatch date of the career file 51 or the concurrent job history file.

  The work / employment history file 52 is a data file for managing the real work place and the assigned duties in the main duties of the employee, and is stored in association with the personal number and the change date. The work / work history file 52 stores information such as the personal number, the date of change, the duties in charge of the main duties, and the date of concurrent service. The work / work history file 52 is subordinate to the concurrent service / work history file. In the part-time work history file, information on the contents of part-time work, such as part-time duties in the main duties, real work place in charge and duties in charge, is stored in association with the individual number and the date on which the part-time work is issued. It is a data file.

  As shown in FIG. 3, the detailed information to be included in the career file 51 and the work history file 52 is managed by another data file and is subordinated to the career file 51. In addition, an increase in size can be avoided. Further, when adding new information to the history file 51, it is necessary to redesign the data file such as the history file 51. However, it is possible to save such trouble by creating another data file and making it subordinate. . Note that the data file managed by the personal information file 50 can be changed as appropriate, such as a data file in which an employee's family structure, work history, performance evaluation, and the like are stored.

  The personnel management device 1 according to the present embodiment uses only the career file 51 when the search condition is “employee who has been in the head office sales for what year, month and day in the competence”. Can be searched. On the other hand, when the search condition is “employee who has been in the head office sales for what year / month / day in the supervisor or concurrent job”, the personnel management apparatus 1 uses both the career file 51 and the concurrent job history file. It is necessary to perform data search (so-called OR search). For this reason, it may be necessary to change the search method or the search time may be significantly different between when searching for data only from the career of the main competence and when searching for data from both careers of the main and concurrent positions. . In the following, a method for performing a search similar to the case of searching for data only from the career of the supervisor even when searching for employees from the career of both the supervisor and concurrently will be described in detail.

  FIG. 4 is a block diagram schematically showing functions realized by the personnel management apparatus 1. Each function shown in FIG. 4 is realized by the CPU 2 executing the program 3 a in the ROM 3. The personnel management apparatus 1 has functions such as a search start unit 10, a virtual database (hereinafter referred to as virtual DB) creation unit 11, a search execution unit 12, a table creation unit 13, and a result output unit 14. The personnel management device 1 has functions such as a personal information file storage unit 15, a connection definition file storage unit 16, and a virtual DB storage unit 17. The personal information file storage unit 15 is a mass storage device 5 and stores a personal information file 50. As described above, the personal information file 50 includes the history file 51 and the work history file 52.

  FIG. 5 is a diagram schematically showing the history file 51. The career file 51 stores the personal number, change date, primary concurrent position, order affiliation, order title, qualification, dispatched date, seconded destination, and concurrent date as one record. The number assigned to each employee is stored in the “personal number” column. The date of change of personnel is stored in the “change date” column. The column of “main concurrent job rank” stores the priority ranks for the primary duties and concurrent duties. Stored in the “Instruction Affiliation” and “Occupation Title” fields are the main office and title. The “qualification” column stores the qualifications the employee has. The “secondary dispatch date” and “secondee” fields store information on the date and secondee of the employee. The “date of concurrent appointment” column stores the date on which the employee's concurrent appointment was issued.

  For example, in FIG. 5, an employee having an individual number of “111111” belongs to the branch A as the main competence on April 1, 2009 and July 1, 2009, and the title is the branch manager's representative. Is shown. On May 1, 2010, he belonged to the head office sales and the position was acting as the head of the group. On October 1, 2012, he became the position of the investigator at the related second place (card company). It shows that. Further, this employee has an A3 qualification on April 1, 2009, and after July 1, 2009, the employee has an A2 qualification. In addition, this employee indicates that concurrent duties other than those in charge are issued on April 1, 2009, May 1, 2010, and October 1, 2012, respectively.

  FIG. 6 is a diagram schematically showing a concurrent job history file. The concurrent job history file stores the personal number, the concurrent job announcement date, the primary concurrent job rank, the concurrent job affiliation, the concurrent job title, the second job start date, and the second job destination information as one record. In the columns of “personal number” and “date of concurrent appointment”, the same information as the “personal number” and “date of concurrent appointment” in the history file 51 of FIG. 5 is stored. That is, the record of the career file 51 is associated with the record of the concurrent job history file. The column of “main concurrent job rank” stores the priority ranks for the primary duties and concurrent duties. In the “concurrent affiliation” and “concurrent post” fields, the affiliation and post that is concurrently held are stored. The fields of “secondary transfer start date” and “secondary transfer destination” store information on the second transfer start date and the second transfer destination, respectively, in the case of a second transfer. For example, in the career file 51 of FIG. 5, a concurrent job is issued on April 1, 2009, and the content of the issued concurrent job is stored in the concurrent job file of FIG. In other words, the affiliation in the concurrently held office is the branch B, and the title is the branch manager's agent.

  FIG. 7 is a diagram schematically showing the seconded history file. The second transfer history file stores personal number, second dispatch date, second dispatch order, second destination and second post information as one record. In the “personal number” and “secondary dispatch date” fields, the same information as the “personal number” and “secondary dispatch date” in the career file 51 and concurrent job history file is stored. That is, the history file 51 or the concurrent record record is associated with the record of the seconded history file. The column of “secondary transfer order” stores information corresponding to “main dual-purpose rank” in the main and concurrent positions. For example, when “00” is stored in the “secondary transfer order” column, information on the seconding of the career of the history file 51 is stored, and when “10” is stored, the concurrent job history file is shared. Indicates that the information on seconding at is stored. In the fields of “secondary transfer destination” and “secondary transfer position”, the affiliation and the post at the transfer destination are stored. For example, in the career file 51 of FIG. 5, the seconding is issued on October 1, 2012, and the contents of the concurrent job that is issued are stored in the seconding history file of FIG. In other words, the dispatched office is the card company, and the second office is the section manager. Further, in the concurrent job history file of FIG. 6, a seconding is issued on May 1, 2010 in the concurrent job, and the contents of the issued concurrent job are stored in the seconded history file of FIG. In other words, the dispatched office is the card company, and the second office is the section manager.

  The search start unit 10 having the function shown in FIG. 4 accepts input of search conditions from the user via the input unit 6. Search conditions include, for example, “Currently enrolled employees who belonged to the head office sales department or the A branch after April 1, 1995”, “What year, what day, and day in the head office sales or the part-time job. It is specified like "employed employee". The data file to be searched is selected from a screen displayed on the monitor of the output unit 7, for example. FIG. 8 is a schematic diagram illustrating an example of a selection screen that displays a list of data files to be searched. A list of data files included in the personal information file 50 is displayed on the screen in a selectable manner. Each data file is a data file (items displayed with white diamonds in the figure) that stores the history of individuals that change in time series, and a data file (black circles in the figure) that stores the history of individuals that occur discontinuously. Items that are displayed), data files that store personal histories that occurred at a certain point in time (items that are displayed with white circles in the figure), and history files of different formats are combined to change in time. A data file (items displayed with black diamonds in the figure) created so that the personal history can be searched, and a data file (displayed with white triangles in the figure) that stores personal histories that overlap with other histories Item).

  When the user selects an item (for example, a career history) displayed as a white diamond, necessary data is searched by searching one data file in time series. On the other hand, when the user selects an item displayed with a black diamond (for example, a career or concurrent career), it is necessary to search a plurality of data files in chronological order. Since it can be used, it is possible to reduce the search time to a level that the user cannot recognize.

  When the user selects an item displayed in white rhombus on the screen of FIG. 8, the search start unit 10 sets the employee including the input search condition to the selected item to the search execution unit 12. Search from the corresponding data file. On the other hand, when the user selects an item displayed in a black diamond shape, the search start unit 10 instructs the virtual DB creation unit 11 to create a virtual DB necessary for the search. Then, the search start unit 10 instructs the search execution unit 12 to execute an employee search including the input search condition from the virtual DB created by the virtual DB creation unit 11.

  The virtual DB creation unit 11 creates a virtual DB from the data file stored in the personal information file storage unit 15 and the connection definition file stored in the connection definition file storage unit 16. The connection definition file storage unit 16 is the mass storage device 5 and stores a connection definition file. The virtual DB storage unit 17 is the RAM 4 and stores the created virtual DB.

  FIG. 9 is a diagram schematically showing a connection definition file. The connection definition file is a data table for defining a relationship between the history file 51 stored in the personal information file storage unit 15 and data files subordinate to the history file 51 and creating a virtual DB. It is. This connection definition file has an information field for storing a main table, main item, vertical table, vertical item, horizontal table, and horizontal item. The vertical and horizontal directions in FIG. 9 mean the row direction (vertical direction) and column direction (horizontal direction) of a virtual DB table to be described later.

  The main data file (history file 51) is defined in the “main table” column, and each item of the data file (history file 51) is stored in the “main item” column. In the column of “vertical table”, a data file (concurrent job history file) to be handled as a record parallel to the main data file (history file 51) in the virtual DB is defined. Each item of the data file (concurrent job history file) defined in the “vertical table” is stored in the “vertical item” column, and is associated with the information stored in the “main item” column. In the “horizontal table” column, in the virtual DB, a data file (secondary transfer history file) to be treated as the same record as the data file defined in the main table and the vertical table (history file 51 and concurrent record file) is defined. Each item of the data file (secondary transfer history file) is stored in the “horizontal item” column, and is associated with information stored in the “main item” and “vertical item” columns.

  FIG. 10 is a diagram schematically illustrating the created virtual DB. The virtual DB stores information of individual number, change date, main concurrent position, second dispatch order date, order assignment, order title, qualification, second place, second place post as one record. Records are arranged in the row direction (vertical direction) of the table of the virtual DB, and store information along the horizontal direction (column direction). Information of the history file 51 is stored in one record of the virtual DB. Since the concurrent job history file is defined as a “vertical table” in the connection definition file, the information of the concurrent job history file is stored in a record different from the history file 51. Further, since the transfer history file is defined in the “horizontal table”, the information of the transfer history file is stored in the record of the history file 51 or the concurrent record history file. In other words, the virtual DB has a record composed of information on the history file 51 and the seconded history file, and a record composed of information on the concurrent job file and the seconded history file.

  For example, the record in the first line of the virtual DB shown in FIG. 10 stores information on the record in the first line of the history file 51 and information on the record in the corresponding seconding history file. Since the record of the concurrent job history file is assigned to the first line record of the career file 51, each column of the second row of the virtual DB includes information on the corresponding concurrent history file record and the concurrent history history file. Stores the record information of the corresponding seconding history file. Since the concurrent appointment date in the concurrent job history file is associated with the change date in the connection definition file in FIG. 9, information on the concurrent date is shown in the column of change date in the virtual DB in FIG. Stored in As described above, the virtual DB shown in FIG. 10 is a data table in which the history file 51, the concurrent job history file subordinate to the history file 51, and the transfer history file are grouped together according to the connection definition file. The number of records having the same personal number and date is calculated from this table, and the maximum value of the calculated number of records is obtained.

  The search execution unit 12 executes a search for employees in response to an instruction from the search start unit 10 that has received an input of search conditions from the user via the input unit 6. When the user selects a data file displayed in white rhombus on the screen shown in FIG. 8, the search execution unit 12 acquires the corresponding data file from the personal information file storage unit 15 and sets the input search condition. Search for employees. In addition, when the user selects an item displayed with a black diamond, the search execution unit 12 searches for employees including the input search condition from the search data table created by the table creation unit 13 described later. .

  The table creation unit 13 creates a search data table (third history table) used by the search execution unit 12. When the user selects an item displayed with a black diamond, the table creation unit 13 obtains a virtual DB from the virtual DB storage unit 17, obtains the maximum number of records having the same personal number and date, and determines the maximum A record length is determined based on the value, and a search data table is created based on the virtual DB. FIG. 11 is a schematic diagram showing a search data table. The table creation unit 13 specifies information on the same date (change date) from the virtual DB acquired from the virtual DB storage unit 17 and calculates the maximum number of records existing on the same personal number and date. If there are a plurality of items, the information specified for the number of calculations, that is, managing director → concurrent job 1 → concurrent job 2 → concurrent job 3, is expanded in the horizontal direction to form one record, thereby creating a search data table. For example, in FIG. 10, the transfer dates in the first and second lines are both “April 1, 2009”. The table creation unit 13 develops these two pieces of information in the horizontal direction. In other words, the record in the first row of the search data table shown in FIG. 11 shows the state of the employee on “April 1, 2009” in the duties and duties (information with “02” in the figure). I remember it.

  As described above, the search execution unit 12 performs an OR search for employees including the input search conditions from the search data table created by the table creation unit 13. For example, if the search condition is “an employee who has a position as a branch manager's representative and has a seconded experience at a credit card company”, the search execution unit 12 records, A record in which “card” is stored first or a record in which both are stored is searched. In the search data table shown in FIG. 11, any record is stored. Accordingly, the search execution unit 12 extracts the employee having the personal number “111111”, assuming that the search condition is met. In this case, when searching for job titles, the number of job title searches is determined based on the maximum number of records so that all job titles can be searched, such as main job → concurrent job 1 → concurrent job 2 → concurrent job 3. Perform a search.

  The result output unit 14 outputs the result executed by the search execution unit 12 from the output unit 7 such as a monitor or a printer. The output mode of the search execution result can be changed as appropriate.

  Next, processing executed in the personnel management apparatus 1 will be described.

  FIG. 12 is a flowchart showing the procedure of the data search process. The process shown in FIG. 12 is executed by the CPU 2. First, the CPU 2 determines whether or not a search condition has been input by the input unit 6 (S1). If it is not input (S1: NO), the CPU 2 ends this process. When the search condition is input (S1: YES), the CPU 2 executes a search execution process according to the search condition (S2). The search execution process will be described later. Then, the CPU 2 outputs the result of the search execution process via the output unit 7 such as a monitor (S3), and ends this process.

  FIG. 13 is a flowchart illustrating a processing procedure of search execution processing.

  The CPU 2 reads the search condition input in S1 of FIG. 12 (S10), and determines whether it is necessary to create a virtual DB from the search condition (S11). Specifically, it is determined whether or not an item (for example, “history of competent or concurrent duties”) displayed in black rhombus is selected on the screen shown in FIG. When it is not necessary to create a virtual DB (S11: NO), the CPU 2 proceeds to the process of S14.

  When it is necessary to create a virtual DB (S11: YES), the CPU 2 creates a virtual DB shown in FIG. 10 (S12). For example, in the case of searching for employees from “history of managing director or concurrently serving”, a connection definition file (see FIG. 9) is obtained from the history file 51, concurrent job history file, and seconded history file described in FIGS. To create a virtual DB. Next, the CPU 2 refers to the virtual DB, obtains the maximum number of records with the same personal number and date, determines the record length based on the maximum value, and creates the search data table shown in FIG. 11 (S13). ). The CPU 2 stores the created virtual DB and search data table in the RAM 4 and deletes the virtual DB and search data table that are no longer needed. Thereby, it is possible to avoid consuming more memory capacity than necessary. Further, by executing creation of the virtual DB and the search data table at the time of executing the search, it is possible to create a virtual DB or the like with information such as the history file 51 being always up-to-date.

  Next, the CPU 2 determines whether or not it is necessary to search for an effective period from the input search condition (S14). For example, if the search condition is “employee who belonged to branch A between 1995 and 2001”, the CPU 2 needs to search for records included between “1995 and 2001”. When it is not necessary to search for the effective period (S14: NO), the CPU 2 proceeds to the process of S16. When it is necessary to search for an effective period (S14: YES), the CPU 2 executes a data restoration search process (S15).

  FIG. 14 is a flowchart showing the procedure of the data restoration search process. The CPU 2 reads one record of data from the data file (S30) and stores the personal number of the data (S31). Next, the CPU 2 determines whether or not the data read in S30 matches the search condition (S32). When the search condition does not match (S32: NO), the CPU 2 returns to the process of S30 and reads the data of the next record. When the search conditions are met (S32: YES), the CPU 2 stores the change date of the read data as the start date of the valid period of the data (S33).

  Next, the CPU 2 reads the data of the next one record (S34), and determines whether or not the personal number of the record matches the personal number stored in S31 (S35). If they match (S35: YES), the CPU 2 determines whether or not the data read in S34 matches the search conditions (S36). If they match (S36: YES), the CPU 2 returns to the process of S34. If they do not match (S36: NO), the CPU 2 stores the day before the change date of the data read in S34 as the end date (S37), and returns to the process of S30. On the other hand, if the personal numbers do not match in S35 (S35: NO), the CPU 2 stores the current date as the end date (S38), and ends this processing. As described above, it is possible to specify a record in a period that matches the search condition. In this case, when performing a search that is not limited to the main duties and concurrent duties, the above-described search is repeated according to the record length, and all of the administrative duties and concurrent duties are searched.

  Next, the CPU 2 determines whether or not it is necessary to calculate the staying days until the date and time (reference date) set in the search condition in the input search condition (S16). For example, if the search condition is “an employee who has been staying at the head office for many years or months”, the number of staying days needs to be calculated. When it is not necessary to calculate the stay days (S16: NO), the CPU 2 proceeds to the process of S18. When it is necessary to calculate the staying days (S16: YES), the CPU 2 calculates the staying days by adding the period matching the search condition within the effective period specified in S15 (S17). Then, the CPU 2 searches for employees that match the input conditions (S18), and ends this process. When searching for employees in S18, if a search data table has been created, the CPU 2 searches for the target employee from the search data table. On the other hand, when the search data table is not created, the CPU 2 searches for the target employee from the acquired data file (for example, the history file 51).

  Next, a specific example of search / extraction of employees that match the search conditions will be described. FIG. 15 and FIG. 16 are schematic diagrams for explaining an employee search / extraction method.

  First, a description will be given of a case where the search condition is set to “employees who have experience in loan business and who have attended loan market staff training at that time”. In this case, a time-series data file of the work / work history file 52 and a data file storing a personal history generated at a certain point in time are to be searched. First, the work history file 52 is referred to and extracted together with a start date and an end date that specify a period experienced by an employee who has experience as a loan clerk by the process shown in FIG. For example, from the work / employment history file 52, an employee with the personal number “111111” can obtain a loan from April 1, 1986 to June 1, 1986 and after August 1, 1986 as shown in FIG. It is extracted that there is experience of the person in charge. Next, a training history file (not shown) is referred to, and employees who have taken the “loan marketer training” as a search condition are extracted. For example, if an employee with the personal number “111111” has a training history, and “Lending Market Personnel Training” as a search condition has been completed on June 1, 1987, FIG. As shown in the figure, the fact that the loan market manager training was taken during the experience of the loan officer is extracted. As described above, the employee with the personal number “111111” is extracted as an employee that matches the search condition.

  Next, a description will be given of a case where the search condition is “employees who were enrolled in head office sales as the main director and were concurrently enrolled as related employees at that time”. In this case, two time-series data files, the history file 51 and the concurrent history file, are to be searched. First, a virtual DB is created from the history file 51 and the concurrent job history file, and a search data table is further created. From this search data table, the employee with the personal number “111111” is extracted as an employee enrolled in the head office sales, and is extracted as shown in FIG. 16 while setting the enrollment period of the head office sales as a start date and an end date. The Next, the employee having the personal number “111111” is extracted by referring to the search data table as “an employee who was concurrently serving as a related employee at that time”. At this time, the enrollment period in which the employee with the personal number “111111” was enrolled in the related seconding was restored as the start date and end date as shown in FIG. 16. It can be seen that there is an overlap with the period of time that was enrolled in the related seconding. As a result, the employee with the personal number “111111” matches the search condition.

  As described above, the personnel management apparatus 1 according to the present embodiment creates one search data table even when another data file (such as a concurrent job history file) is subordinate to the history file 51. This makes it easy to search for the target employee. In addition, by searching from a single search data table, not only the date of occurrence of data but also the job history when searching for employees based on an arbitrary date, using the search method that has been used in the past. , You can search including the concurrent history. In recent years, the concurrent job history has become complicated in order to produce maximum results with limited personnel, and the importance of being able to search the concurrent job history in personnel evaluation has increased. By making such a search suitable for the background possible, it will lead to effective personnel assignment and accurate personnel evaluation. In addition, the history is stored for each date and time when data is generated, so that data managed in a so-called data generation principle is restored to the period in which the data is valid according to the date and time of data generation, and this restored data is used. Thus, the data can be handled continuously, and the search / extraction process of data belonging to the specified time as described above, that is, the data becomes valid at the specified time can be automatically realized.

  The preferred embodiment of the present invention has been specifically described above, but each configuration, operation, and the like can be changed as appropriate, and are not limited to the above-described embodiment. For example, FIG. 17 is a schematic diagram of another example of the personnel management apparatus according to the embodiment. In FIG. 17, the personnel management apparatus 1 is connected via a network N to a mass storage device 20 that stores a personal information file 50. The network N is a local area network (LAN) or a wide area network (WAN). The personnel management apparatus 1 may acquire a data file such as the personal information file 50 via the network N. In this case, the personnel management device 1 may not include the mass storage device 5. A plurality of personnel management devices 1 may be connected to the mass storage device 20 via the network N. Furthermore, in the above-described embodiment, only the employee with the personal number “111111” is extracted. However, when there are a plurality of employees that match the search condition, it is natural that the employees with other personal numbers are also extracted. It is.

1 Personnel management device 5 Mass storage device 10 Search start part (acceptance part)
11 Virtual DB creation unit 12 Search execution unit (first and second extraction units, history period calculation unit)
13 Table creation unit 14 Result output unit 15 Personal information file storage unit 16 Link definition file storage unit 17 Virtual DB storage unit

Claims (6)

A first history table that associates personal histories and dates and stores each date uniquely;
A second history table corresponding to the date and storing a history different from the history;
A history specifying unit for specifying a history having the same date stored in the first and second history tables;
When there are a plurality of histories specified by the history specifying unit, the maximum number specifying unit for counting the total number of histories having the same date and specifying the maximum value;
Generating a third history table having a cell for storing the history of the number of items corresponding to the maximum value specified by the maximum value specifying unit and a cell for storing the date in association with each other; and the first and second history tables A table creation unit for storing the history accumulated in the third history table for each date;
A reception unit for receiving a search condition including a search item;
A first extraction unit for extracting a history corresponding to the corresponding search item from the third history table based on a search item included in the search condition received by the reception unit;
A history period calculation unit that obtains the date of the history and calculates the period of the history based on the date of the next history;
An information search device comprising: a second extraction unit that extracts a history corresponding to a search condition based on a history extracted by the first extraction unit from the third history table and a period calculated by the history period calculation unit . A plurality of the second history tables;
The history specifying unit
The dates accumulated in the first history table and the plurality of second history tables specify the same history,
The table creation unit
The information search apparatus according to claim 1, wherein histories accumulated in the plurality of second history tables are stored in the third history table. The reception unit
Accept search conditions including the search period,
The first extraction unit includes:
Read the corresponding history sequentially from the third history table,
The history period calculation unit
Identify the validity period based on the period received by the reception unit and the date in the history,
The second extraction unit includes
The information search device according to claim 1 or 2, wherein a history corresponding to a search condition designated by the reception unit is extracted from a history within a specified effective period. The reception unit
Accept search criteria including the total number of validity periods,
The second extraction unit includes
When the history period calculation unit identifies a plurality of effective periods that are discontinuous in time, the plurality of effective periods are added together, based on the total result and the total number of effective periods specified from the reception unit, The information search device according to claim 3, wherein a history is extracted. Information retrieval executed by a computer comprising a first history table that stores personal history and date in association with each other uniquely and a second history table that corresponds to the date and stores a history different from the history In the method
Identifying the history with the same date accumulated in the first and second history tables;
If there are multiple identified histories, count the number of histories, identify the maximum value,
A third history table having a cell for storing the history of the number of items corresponding to the specified maximum value and a cell for storing the date in association with each other is generated, and the history stored in the first and second history tables is generated. Storing each date in the third history table;
Accept search conditions including search items,
Based on the search item included in the received search condition, a history corresponding to the corresponding search item is extracted from the third history table,
Obtaining the history date and calculating the history period based on the next history date;
An information search method for extracting a history corresponding to a search condition based on a history extracted from the third history table and a calculated period. A computer-executed program comprising a first history table that uniquely stores each history and date in association with each other, and a second history table that corresponds to the date and stores a history different from the history In
Computer
A history specifying unit for specifying a history having the same date stored in the first and second history tables;
When there are a plurality of histories specified by the history specifying unit, the maximum value specifying unit for counting the number of histories and specifying the maximum value
Generating a third history table having a cell for storing the history of the number of items corresponding to the maximum value specified by the maximum value specifying unit and a cell for storing the date in association with each other; and the first and second history tables A table creation unit that stores the history accumulated in the third history table for each date;
A first extraction unit for extracting a history corresponding to the corresponding search item from the third history table based on the search item included in the search condition that has received the search condition including the search item;
A history period calculation unit that obtains the date of the history and calculates the period of the history based on the date of the next history, and
The program which functions as a 2nd extraction part which extracts the log | history applicable to search conditions based on the log | history which the said 1st extraction part extracted from the said 3rd log | history table, and the period calculated by the said log | history period calculation part.

Images