JP2012243213A - Data processing method and data processor - Google Patents

Abstract

PROBLEM TO BE SOLVED: To improve the operability of search processing in a small-scaled device such as a camera by quickly processing search result outputs arranged in a chronological order from a database without performing sort processing.SOLUTION: Internal IDs each uniquely specifying line data are necessarily arranged in a chronological order, and the storage order of lines whose values are made the same in each index is set to the order of the internal IDs so that it is possible to acquire the line data in a chronological order from the index. Therefore, it is unnecessary to perform processing to finally sort search results in the chronological order. Thus, it is possible to achieve a data processing device for outputting the search results arranged in the chronological order with a small amount of resources even in the small-scaled device, and for increasing cost performance even in the small-scaled device.

Description

  The present invention relates to a data processing method and a data processing apparatus, and more particularly to a technique suitable for use in performing a search in a database.

  In recent years, storage and recording media have been increased in capacity, and data processing with a heavy processing load such as search is being performed even in small devices such as cameras. In response to the increased data processing load, database management systems (DBMS) have been developed in the fields of large-scale servers and the like, and the development of application systems using DBMS has contributed to improving system development efficiency. . Therefore, a DBMS (embedded database) suitable for a built-in device has been proposed and used to utilize the DBMS in a small device.

  In general, in the application of a device, the order of search results (output order) is in a predetermined order, for example, data registration time order (shooting order for cameras, recording order for TVs, job generation order for copiers). There are many cases to ask for. Usually, in order to correspond to this predetermined order, the database (1) first extracts a test result set. (2) Next, since the set is processed in two stages of sorting in the designated order, the sorting process always occurs. Sort processing is not a problem for a device having a large resource such as a server, but a heavy load is a serious problem for a device having a low resource such as a camera.

  There have been proposals for reducing the sort processing in such a database. For example, in Patent Document 1, a comparison is made between a search condition and an index structure, and it is determined whether or not the record reading via the index has the same effect as the sorting process. The technique of searching by omitting is disclosed.

JP-A-8-255170

  The above-mentioned countermeasure according to Patent Document 1 uses whether or not the index stored in the order of the sort keys happens to be present, and is a method that can only be effective when it exists. On the other hand, a device that can surely obtain an effect is required for a low-resource device such as a camera.

Actually, in the case of a camera, the search results are mostly sorted in order of shooting time. If the time order sort is fast, it is practical enough, and it is not necessary to speed up the arbitrary sort order output.
In view of the above-described problems, the present invention realizes a database capable of processing search results in time order with a small load even at low resource devices such as cameras, thereby improving the operability of on-device search. The purpose is to be able to.

  The data processing method of the present invention is configured such that row data that can be uniquely specified by an internal ID is configured, and pairs of registration times held in the internal ID and the row data form a total order relationship. A data processing method for performing a search in a database, wherein a row data acquisition step of acquiring the row data in the order of the internal ID, and determining whether or not the acquired row data satisfies a user-specified search condition And a row data output step for outputting row data when it is determined that the condition is satisfied in the search condition determination step, and the search results are output in the order of registration time.

  According to the present invention, when the search results are output in time order, the final time order sorting process after extraction of the search result set can be omitted, so that even in low resource devices, the time order search results can be output at high speed. it can.

It is a block diagram which shows 1st Embodiment and shows the whole structure of a data processor. It is the figure which showed the example of a process of the search in a data processor. It is the figure which showed the storage structure of the database in a data processor. It is the figure which showed the example of the process of export / import of a data processor. It is a figure explaining the import processing method according to all the order relations. It is a flowchart which shows an example of the process sequence of the whole apparatus. It is a flowchart which shows an example of the process sequence of a search process. It is a flowchart which shows an example of the procedure of an import process. It is a flowchart which shows an example of the process sequence of an internal ID readjustment process. It is a block diagram which shows the whole structure of the data processor of 2nd Embodiment. It is the figure which showed 3rd Embodiment and showed the implementation example of internal ID.

(First embodiment)
Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the drawings.
FIG. 1 is a block diagram illustrating a configuration of a data processing device 100 according to the first embodiment.
In the configuration shown in FIG. 1, the CPU 101 is a microprocessor, and performs operations such as search processing, export processing, import processing, shooting processing, screen transition processing, logical determination, etc., and is connected to the bus via the bus. Control each component.

  The BUS 106 transfers an address signal and a control signal instructing each component that is a control target of the microprocessor CPU (Central Processing Unit) 101. In addition, data transfer between each component is performed. The input unit 102 is a button, a touch panel, a keyboard, or the like, and an operator gives various instructions. The display unit 103 is a liquid crystal display or the like.

  The imaging unit 104 is an imaging sensor or the like, and is a device that reads an image and converts it into electronic data. The communication unit 105 is a data exchange controller. This is a device for exchanging data with the outside via a wireless LAN, a connection cable or the like. Data imported in the import process and data exported in the export process are exchanged with an external device via the communication unit 105.

  The ROM 107 is a read-only nonvolatile memory. A boot program by the CPU 101 and initial data used in various processes are stored. The boot program loads initial data into the RAM 108 when the system is started, and causes the CPU 101 to execute the control program. The control program will be described in detail later with reference to a flowchart.

  A RAM 108 is a readable / writable random access memory, and is used for primary storage of various data from each component. Various data whose values are changed during processing, such as a stack for processing data, various work areas for temporarily storing necessary data, and a buffer for temporarily storing display data necessary for display, are stored. Data imported in the import process is also temporarily stored in the RAM 108 and processed.

  The DISK 109 is a large-scale storage device for storing a large amount of data in a changeable manner. It consists of a hard disk or flash memory. Row data, indexes, and the like used in the data processing apparatus 100 of the present embodiment are stored, and the contents are corrected as necessary.

  The data processing apparatus 100 according to the first embodiment including the above-described components operates according to various events input via the input unit 102 or the like. An interrupt signal is sent from the input unit 102 or the like to the CPU 101, and an event is generated accordingly. The CPU 101 reads various commands stored in the ROM 107 or the RAM 108 according to the event, and various controls are performed by executing the commands.

  FIG. 2 is a diagram illustrating an example of search processing targeted by the first embodiment. The user designation of the search is performed by the user instructing the touch panel or the like, and the received search instruction is interpreted by the application and passed to the DBMS in the form of a search query described in a DB operation language (SQL sentence or the like). It will be.

  FIG. 2A is a diagram illustrating an example of a search query (SQL sentence). It is specified that a photo whose subject (Person) is 'Kate' is searched from a database (PhotoAlbum) that is managed so that a set of photos can be searched by attribute, sorted and output in order of shooting time (Time). . In the first embodiment, a camera is assumed, the shooting time means data registration time, and the shooting time order means registration time order.

  FIG. 2B shows search processing for the search query in FIG. There is a photo set 201 that collects and manages a large number of photos. First, in the first step (step 1), photos satisfying the search condition are extracted from the photo set 201 to create a photo list 202 that becomes a search result set. In the next step (step 2), the photos in the photo list 203 are sorted in the order of shooting times specified by the search query, and the sorted photo list 203 is created. In this case, the sorting process in step 2 places a corresponding load on the system. If the photos can be extracted in the order of the finally obtained photo list 203 at the stage of step 1, the process of step 2 can be omitted.

  FIG. 2C shows an example of a search process when the sort process can be omitted. This time, when extracting the photos that match the search query from the photo set 204, as shown in (1) to (4), the photos are extracted in the order of the shooting time, which is the final output order, and the photos in that order. A list 205 is created. In this way, the final sorting process can be omitted, so that the processing load can be reduced.

FIG. 3 is a diagram showing a database storage structure in the first embodiment. Basically, it has a so-called B-Tree (tree structure) structure.
FIG. 3A shows a storage structure of row data. The row data is stored in a B-Tree format using an internal ID (referred to as RowID) that can uniquely identify the row as a key. Note that the internal ID is an ID for uniquely identifying the row data, and there is a restriction that it should not be duplicated.

  For this reason, usually, each database has a different system and is used as an ID closed inside. The database storage unit is a node 301, which is composed of a plurality of nodes. Each node is composed of a key 302 and a branch 303, and the target node can be traced from the highest node (root node) by determining the key size relationship and following the branch. In the lowest layer node (leaf node), a plurality of row data 304 is stored in the order of RowID. The row data includes a RowID 305 for specifying a row, shooting time information 306, and other columns 307. Here, since RowID is in time (shooting time information) order, the storage order is in time order.

  The index is prepared to speed up the search when it is desired to search the row data according to the attribute. An index is created for each attribute that requires high-speed search. FIG. 3B shows an example of an index storage structure. The index of the person name (Person) is shown. It has a B-Tree structure with Person as a key. This is basically the same as the storage structure of the row data, except that a pair of Person (308) and RowID (309), which is a key, is stored in the lowermost leaf node instead of the row data. When the value of Person is the same, each pair is stored in the order of RowID, that is, in order of time (shooting time information). As described above, even when searching through the index, the row data can be acquired in time order.

  FIG. 4 is a diagram showing an example of export / import processing in the first embodiment. At the time of export, the partial database DB2 (402) is exported from the internal database DB1 in the device 1 (401) and output to the outside. At this time, it is output including RowID information which is originally internal ID information. Hereinafter, the database DB1 is called an export source database, and DB2 is called an export destination database. The exported database DB2 is transferred to the device 2 (403) and stored in a temporary storage area in the device 2. Alternatively, the data is transferred to an external medium such as an SD card once the external medium is attached to the device 2.

  Next, at the time of import, the transferred database DB2 is imported into the internal database DB3 in the device 2 (403). Hereinafter, DB2 is called an import source database, and DB3 is called an import destination database. At this time, the value of the RowID is adjusted and imported so that the relationship between the value of the RowID and the time information does not contradict within the import destination database DB3. For example, the row data of RowID = 50 in the import source database DB2 is changed to RowID = 1 and imported.

FIG. 5 is a diagram illustrating an import processing method according to the total order relationship in the first embodiment.
FIG. 5A is a diagram showing an example of data to be imported (imported row data). As described with reference to FIG. 4, the row data is generated by being exported from another database. The row data consists of columns of RowID (501), shooting time information (502), and other information (503). As described in the description of FIG. 4, RowID (501) is originally an ID that is used only internally, and is usually data that is not exported. However, in the first embodiment, it is exported. .

  FIG. 5B is a diagram illustrating an import example when the total order relationship can be maintained. A DB before import is indicated by 504, and a DB after import is indicated by 505. In the DB 505 after the import, the thick frame portion is the row data in which FIG. Since the pair of (RowID, shooting time) has a total order relationship in the DB of the import destination in the DB, it can be seen that the RowID is imported as it is without being changed.

  FIG. 5C shows an import example when the total order relationship cannot be maintained. Similarly, the DB before import is indicated by 506, and the DB after import is indicated by 507. Similarly, in the DB 507 after import, the row data in the thick frame portion is the imported row data, but it can be seen that the value of RowID is changed this time.

  That is, since the pair of (RowID, shooting time) does not have a total order relationship with the immediately preceding or immediately following shooting time row if the RowID remains unchanged, the value of the RowID is adjusted so that the total order relationship is satisfied. Was imported. The row data of 508 is imported by adjusting the value of RowID (RowID = 15) so that it is between the row of the previous shooting time (RowID = 10) and the row of the next shooting time (RowID = 20). Yes.

  In the row data 509, there are a plurality of rows (RowID = 30 and 40) of the immediately preceding shooting time, but between the maximum value (RowID = 40) and the row of the immediately following shooting time (RowID = 50). Adjusted (RowID = 45) and imported. In the row data 5010, there is no space between the immediately preceding shooting time row (RowID = 70) and the immediately following shooting time row (RowID = 71), and a new intermediate RowID cannot be set. The peripheral RowID has been changed to be a discontinuous value. That is, the row with RowID = 71 is changed to 80, and the row with 72 is changed to 90. Thereafter, an intermediate value immediately before and after (RowID = 75) is obtained and imported.

The above operation will be described with reference to a flowchart.
FIG. 6 is a flowchart illustrating the operation of the data processing apparatus 100 according to the first embodiment. More specifically, it is a flowchart showing a processing procedure of the CPU 101. S601 is a system initialization process, which initializes various parameters, displays an initial screen, and the like.

  In step S602, the CPU 101 waits for an event to occur from the input unit 102 such as a touch panel. When an event occurs, the CPU 101 determines this event in S603, and branches to various processes depending on the type of event. In FIG. 6, a plurality of branch destination processes corresponding to various events are collectively expressed in the form of S604.

The search process detailed in FIG. 7 and the import process detailed in FIG. 8 are part of this branch destination. Other processes include processes such as an export process, a photographing process, a photo browsing process, a communication process, and a power-off process, although details are not described.
S605 is a process for notifying the result of each process and the end of the process, and displaying the screen according to the instruction for each process. This is a process that is usually performed widely, such as displaying an error when there is an error and reflecting it on the screen display when normal processing is performed.

FIG. 7 is a detailed flowchart of the search process that is a part of S604 of FIG.
In step S701, variables and tables that need to be initialized are initialized, and a processing index corresponding to the search condition is selected. For example, for the query “SELECT * FROM PhotoAlbum WHERE Person =“ Kate ”AND Place =“ Tokyo ”ORDER BY Time”, the index of Person is selected.

In S702, a search range is set from the search conditions, and a pointer is initially set at the head of the range. For example, the B-Tree of the Person index is traced, and a pointer is set at the start position of Kate.
In S703, the value of RowID is acquired according to the pointer, and this time, the B-Tree of the row data is traced to acquire the row data. In accordance with the data structure of the B-Tree already described, the row data acquisition process is always performed in the order of RowID, that is, in order of photographing time.

  In step S704, it is checked whether the acquired row data satisfies the search condition. For example, in the previous example, a search condition determination is performed to check whether or not “Place =’ Tokyo ”is satisfied. In S705, a search condition determination process is performed. If the search condition is satisfied, the process proceeds to S706, and if not satisfied, the process skips to S707.

In S706, row data output processing is performed because the search condition is satisfied. As a result, the search result is output.
In S707, it is determined whether or not the pointer is at the end position of the search range. If the pointer is at the end position, no further processing is required and the process returns. If not, the process branches to S708. In step S708, the pointer is updated to point to the next row data in the search range, and the process loops to S703.

FIG. 8 is a flowchart detailing the import process that is a part of S604.
In step S801, a set of row data to be imported is acquired. The imported row data is temporarily stored in the RAM 108 in the device, for example. In S802, one row data to be imported is acquired. Internal ID acquisition and shooting time acquisition of the row are performed, RowID is R, and shooting time is T.

  In step S803, it is determined whether or not the row data can be acquired. If the row data cannot be acquired, the process ends. If acquired, the process proceeds to step S804. In S804, it is checked whether or not there is a RowID row having the same value as R in the import destination database. That is, an internal ID collision check is performed.

  In step S805, internal ID collision determination is performed to determine whether or not there is an ID collision. If there is a RowID with the same value, that is, if the RowID collides, the process branches to S811, but if not, the process branches to S806. In S806, a RowID that is smaller than R and closest to R is acquired from the import destination database, and the value is set as R1.

  In S807, the shooting time of the row R1 is acquired and set to T1. In S808, a RowID greater than R and closest to R is acquired from the import destination database, and the value is set as R2. In S809, the shooting time of the row R2 is acquired and set to T2.

  In S810, it is determined whether T1 <T <T2 is satisfied. That is, a total order relation determination is performed, and if the total order relation is not established, the process branches to S815, and if the total order relation is established, the process branches to S816. In S815, processing is performed when the total order relationship does not hold. That is, the row ID of the import destination database or the imported row data is adjusted by calling the internal ID readjustment process described in detail in FIG. 9 with the imported row data as an argument. In S816, the row data is imported, and the process proceeds to S817.

  On the other hand, if the RowID collides in S805, the process branches to S811, and in S811, it is determined whether or not all the columns of the two conflicting row data are the same. If it is the same line data, it is not necessary to perform the import process in the first place, so the process branches to S817 to move to the next line data. If not identical, the process proceeds to S812.

  In S812, it is checked whether or not the row data needs to be synchronized (synchronized data). The check method determines that synchronization is required when the contents indicated by the row data match. As another check method, a method may be conceived in which ID information for uniquely specifying content is determined in advance, the information is stored in a row data column, and the determination is made based on the matching of the information.

  In step S813, it is determined whether the data is synchronous data. If it is not synchronous data, the process branches to S815, and if it is synchronous data, the process proceeds to S814. In S814, synchronization processing is performed. The synchronization process is a process of selecting and updating a new line from the two line data. Or, it may be updated to new data in units of columns. In that case, the difference is extracted to determine which is the latest and updated. Alternatively, there is a case where a process for causing the user to select which data is selected is performed. Thereafter, the process proceeds to S817. In S817, the pointer is updated to point to the next row data, and the process loops to S803.

FIG. 9 is a flowchart detailing the internal ID readjustment process of S815.
In S901, the shooting time of the row data to be imported is acquired and set as T. In step S902, a shooting time that is present in the import destination database and is smaller than T and closest to T is acquired, and is set as T1. In step S903, the maximum RowID among the row (s) having T1 as the shooting time is R1.

  In S904, an imaging time that is present in the import destination database and is greater than T and closest to T is acquired, and is set as T2. In S905, the minimum RowID among the (plurality of) rows having T2 as the shooting time is R2. In S906, R satisfying R1 <R <R2 is acquired.

  In S907, it is determined whether or not R exists. If it does not exist (that is, if R1 and R2 are serial numbers), the process branches to S908. In S908, the row IDs in the row data to be imported are renumbered so that the values of the row IDs in the vicinity of R1 or R2 do not become sequential numbers (that is, become discontinuous values). This renumbering can be performed on the entire import destination database, but it may be locally renumbered in the vicinity of R1 and R2. Thereafter, the process loops to S906. If the value of R exists in S907 (that is, if R1 and R2 are not continuous values), the process branches to S909, changes the RowID of the imported row data to R, and returns. It should be noted that the present invention is not limited to the above-described embodiment, and various modifications can be made without departing from the spirit of the present invention.

(Second Embodiment)
In the embodiments described so far, the description has been made assuming that export processing, import processing, and the like are executed on a device such as a camera. However, there is a usage in which data such as photographs taken with a camera is centrally managed by a PC or the like, and necessary data is distributed to the device and browsed on the device. In such a case, it is not necessary to perform complicated import processing on a camera with few resources, and it is more appropriate to perform import processing for the camera on the PC. In the second embodiment, the operation when the import process is realized on the PC will be described.

FIG. 10 is a diagram illustrating an example of the overall configuration of a system according to the second embodiment.
FIG. 10A shows the overall configuration, which is very similar to the overall configuration shown in FIG. Only the differences will be described.
The configurations and roles of the CPU 1001, the input unit 1002, the display unit 1003, the communication unit 1004, the BUS 1006, the ROM 1007, the RAM 1008, the DISK 1009, and the like are almost the same.

  In the present embodiment, since it is a PC, the imaging unit 104 in FIG. 1 does not exist. A device 1005 (for example, a camera) is connected via the communication unit 1004, and a database (device DB1) on the device can be referred to. The extracted data area is used as a work area in the RAM 1008, and the entire DB and device DB2 are stored in the DISK 1009.

  Data (photographs, etc.) obtained from a plurality of devices is centrally managed in the entire DB. The device DB is a work area used when importing data into a device. At the time of import, the database (device DB1) on the device is temporarily copied to the device DB2.

  Of the data stored in the entire DB, the data to be imported to the device is once extracted in the extraction data area and imported into the device DB 2 thus copied. After the import process is completed, this device DB2 is written back to the device DB1 on the device, and finally the device can be used.

  FIG. 10B shows a logical structure (table format) of the entire DB. The physical structure is the B-Tree structure described with reference to FIG. There are 1010 columns as the original RowID used when processing the database. Separately, the entire DB stores all RowID information when each device is using the DB.

  In this case, reference numerals 1011 and 1012 indicate the information of two devices. For example, it is assumed that the RowID for the device DB1 is stored in the column 1010. The shooting time information is stored in a column 1013, and the information in the other columns is collectively shown by 1014. Thus, the information in the entire DB is held together with all the information held by each device.

  When importing into a device, it is first necessary to extract data that needs to be imported, and the extracted data is created in the extracted data area (1015). At the time of this extraction, a target device is specified, and only RowID information for the device is extracted. The configuration of the device DB 2 is indicated by 1016, and the extracted data is imported here.

  With this configuration, RowIDs corresponding to a plurality of devices can be held in the PC, so that the possibility of starting RowID adjustment processing is reduced, and system performance can be improved.

(Third embodiment)
In the embodiments described so far, the internal ID is not particularly defined and explained as a value along the time. Actually, various forms of internal IDs as shown in FIG. 11 are conceivable depending on the circumstances of the equipment and functions.

  FIG. 11A is a diagram illustrating an example of using data registration order information. The order in which the data is registered is indicated by 1101, and the time when the data is registered (registration time) is indicated by 1102. Registration order information is given according to the context of the registration time 1102. According to this method, the mechanism for issuing the internal ID can be simplified, and the system can be realized with low resources.

  FIG. 11B is a diagram illustrating a case where the data registration time is adopted as the internal ID. The registration time is indicated by 1103, YYYY is the year, MM is the month, DD is the day, hh is the hour, mm is the minute, and ss is the second. On the other hand, an example of an internal ID (RowID) calculation formula is shown by 1104. Here, the formula for calculating the number of seconds from the starting date with the number of days of the month fixed to 31 is simply used. However, more precise formulas such as the size of the month, leap years, etc. are also easy to calculate. Can be given to. This form has the advantage that the numbering is easy and the consistency of the order among the plurality of devices is easy. However, when a large number of data are registered at the same time (for example, when continuous shooting is performed with a camera), the possibility of a collision of internal IDs increases.

FIG. 11C shows a method in which the possibility of collision is lowered. A constant multiple of the registration time described above is used as the internal ID. When the registration time is given by 1103, the internal ID (RowID) is given by the formula 1105 in the same manner. Here, C means a constant, and is used with a value such as C = 10, for example. Thereby, the probability of an internal ID collision can be greatly reduced.
In addition to the embodiments described above, the configuration can be changed as appropriate without departing from the spirit of the present invention.

(Other embodiments)
The present invention can also be realized by executing the following processing. That is, a data processing program (computer program) that implements the functions of the above-described embodiments is supplied to a system or apparatus via a network or various computer-readable storage media. Then, the computer (or CPU, MPU, etc.) of the system or apparatus reads out and executes the program.

100 data processing device, 101 CPU, 102 input unit, 103 display unit, 104
Imaging unit, 105 communication unit, 106 communication unit, 107 ROM, 108 RAM, 109

Claims (7)

Data that is searched for in a database that is configured so that the row ID that can be uniquely specified by the internal ID and the pair of registration times held in the internal ID and the row data form a total order relationship. A processing method,
A row data acquisition step of acquiring the row data in the order of the internal IDs;
A search condition determination step of determining whether or not the acquired row data satisfies a user-specified search condition;
A data processing method comprising: a row data output step of outputting row data when it is determined that the condition is satisfied in the search condition determination step, and the search results are output in order of registration time. An export step of outputting the row data including the internal ID to an export destination when exporting the row data from the database;
An internal ID acquisition step of acquiring the internal ID and registration time of the row data of the import source when importing the exported row data into the database;
An internal ID collision determination step of determining whether the acquired internal ID does not collide with the internal ID of the import destination database;
A total order relation determining step for determining whether the pair of the acquired internal ID and shooting time can maintain the total order relation with the pair of the internal ID and registration time of the import destination database;
An importing step of importing the row data when it is determined that there is no collision in the internal ID collision determination step and it is determined that the total order relationship is maintained in the total order relationship determination step. The data processing method according to claim 1, wherein:   The data processing method according to claim 1 or 2, wherein either the registration time, a constant multiple of the registration time, or registration order information is used as the internal ID.   When it is determined in the total order relationship determination step that the total order relationship is not maintained, the import step allows the internal ID of the import row data or the internal row data of the import destination database so that the total order relationship can be maintained. 3. The data processing method according to claim 2, wherein the row data is imported after changing the ID. Data that is searched for in a database that is configured so that the row ID that can be uniquely specified by the internal ID and the pair of registration times held in the internal ID and the row data form a total order relationship. A processing device comprising:
Row data acquisition means for acquiring the row data in the order of the internal IDs;
Search condition determination means for determining whether or not the acquired row data satisfies a user-specified search condition;
A data processing apparatus comprising: row data output means for outputting row data when the search condition determining means determines that the condition is satisfied, and outputting the search results in the order of registration time. A database holding row data that can be uniquely specified by an internal ID, wherein the internal ID and a pair of registration times held inside the row data form a total order relationship, and the row data is stored in the internal ID. Row data acquisition process to acquire in the order of,
A search condition determination step of determining whether or not the acquired row data satisfies a user-specified search condition;
A data processing program that causes a computer to execute a row data output step of outputting row data when it is determined that the condition is satisfied in the search condition determination step, and outputs search results in order of registration time.   A computer-readable storage medium storing the data processing program according to claim 6.

Images