WO2010084754A1 - データベースシステム、データベース管理方法、データベース構造および記憶媒体 - Google Patents

データベースシステム、データベース管理方法、データベース構造および記憶媒体 Download PDF

Info

Publication number
WO2010084754A1
WO2010084754A1 PCT/JP2010/000326 JP2010000326W WO2010084754A1 WO 2010084754 A1 WO2010084754 A1 WO 2010084754A1 JP 2010000326 W JP2010000326 W JP 2010000326W WO 2010084754 A1 WO2010084754 A1 WO 2010084754A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
identifier
database
tuple
area
Prior art date
Application number
PCT/JP2010/000326
Other languages
English (en)
French (fr)
Inventor
上村純平
柏木岳彦
Original Assignee
日本電気株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電気株式会社 filed Critical 日本電気株式会社
Priority to US13/144,828 priority Critical patent/US20110289112A1/en
Priority to JP2010547440A priority patent/JPWO2010084754A1/ja
Publication of WO2010084754A1 publication Critical patent/WO2010084754A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2255—Hash tables
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing

Definitions

  • the present invention relates to a database structure and a technique for executing data processing on the database.
  • RDBMS Relational DataBase Management System
  • RDB Relational DataBase Management System
  • the RDBMS manages data in units of rows using a unique key for each row, it can execute large-scale processing in units of rows at high speed and efficiently, but large-scale processing in units of columns. There is a problem that it is difficult to execute efficiently. For example, when RDBMS executes data processing in units of columns, it is necessary to read data of a plurality of rows corresponding to the columns requested by the query, which causes a problem of reducing the processing speed. Furthermore, since the RDBMS can write data in a continuous storage area in the memory in units of rows, the data can be accessed at a high speed in units of rows. However, when the RDBMS executes a transaction related to search processing, comparison operation, or aggregation operation in units of columns, a phenomenon of frequently accessing data stored in a plurality of non-contiguous memory areas occurs. Processing speed may decrease.
  • DWH Data WareHouse
  • the DWH is a system that is constructed independently of the core business system and does not update data (addition of new data, change of existing data, or deletion of existing data) in principle. Therefore, DWH does not have a database structure that can perform data update efficiently.
  • Patent Document 2 Japanese Patent Laid-Open No. 2000-339390
  • Patent Document 3 International Publication No. 00/10103 pamphlet
  • the database systems of Patent Document 2 and Patent Document 3 are database structures obtained by converting logical tabular data into, for example, a plurality of information blocks corresponding to respective items of gender, age, height, and weight. Is used.
  • Each information block includes a value management table (value list) and a pointer array to the value management table.
  • the pointer array to the value management table means that an item value number (that is, a pointer to the value management table) of a certain column of tabular data is in a predetermined order (record number order) of the tabular data.
  • a stored array is
  • the item value numbers in the value management table are arranged in a predetermined order in order to speed up data update (for example, record update, insertion or deletion). Is required. For this reason, when a new item value number is inserted into the value management table at the time of data update, it is necessary to rearrange other existing item value numbers.
  • the pointer array to the value management table must be updated so that it matches the item value number after the rearrangement. Therefore, with the database structures of Patent Document 2 and Patent Document 3, data update cannot be executed efficiently and at high speed. In particular, when data is updated frequently, there is a problem that the processing load becomes extremely large and the processing speed is significantly reduced.
  • an object of the present invention is to provide a database system, a database management method, a database structure, and a storage that enable efficient and high-speed execution of data update to a database and can also improve the processing speed of search and aggregation. To provide a medium.
  • a data storage unit having a database including a plurality of entity data, and a data processing unit that receives a query and executes data processing based on the received query with respect to the database.
  • a database system is provided.
  • the database has a fixed-length data identifier that uniquely represents the entity data itself in an area defined by at least one tuple defined in the row direction and at least one attribute field defined in the column direction.
  • the identifier table has a metadata area in which a tuple identifier uniquely representing the tuple in which each data identifier is stored is stored.
  • a database structure including a plurality of entity data.
  • a fixed-length data identifier that uniquely represents the entity data itself is stored in an area defined by at least one tuple defined in the row direction and at least one attribute field defined in the column direction.
  • An identifier table; and a conversion table representing a correspondence relationship between the plurality of data identifiers and position data indicating positions of the storage areas of the plurality of entity data, and the conversion table is the identifier table in the identifier table It has a metadata area for storing a tuple identifier that uniquely represents the tuple in which each data identifier is stored.
  • the database is a fixed-length data identifier that uniquely represents the entity data itself in an area defined by at least one tuple defined in the row direction and at least one attribute field defined in the column direction.
  • the identifier table has a metadata area in which a tuple identifier uniquely representing the tuple in which each data identifier is stored is stored.
  • a process for receiving a query for a database that is a computer-readable recording medium and includes a plurality of entity data, and a data process that is executed on the database based on the received query And a storage medium storing a computer program that causes the computer to execute a database management process.
  • the database includes an identifier in which a fixed-length data identifier uniquely storing the entity data itself is stored in an area defined by at least one tuple defined in a row direction and at least one attribute field defined in a column direction.
  • a table, and a conversion table representing a correspondence relationship between position data indicating the position of the storage area of each of the plurality of entity data and the plurality of data identifiers.
  • the conversion table has a metadata area in which a tuple identifier uniquely representing the tuple in which each data identifier is stored in the identifier table is stored.
  • updates to the database can be executed efficiently and at high speed, and processing such as search and tabulation can also be executed at high speed.
  • FIG. 1 It is a functional block diagram which shows schematic structure of the database system of one Embodiment which concerns on this invention. It is a flowchart which shows roughly the process sequence of the transaction processing part of a database system. It is the schematic which shows an example of the logical structure of the database which concerns on the 1st Embodiment of this invention. It is a figure which shows an example of a real table typically.
  • (A) to (C) are diagrams showing a logical data structure of a database.
  • (A) And (B) is a figure which shows roughly the 1st modification of the conversion table of the database which concerns on 1st Embodiment.
  • (A) And (B) is a figure which shows roughly the 2nd modification of the conversion table of the database which concerns on 1st Embodiment.
  • (A) And (B) is a figure which shows roughly the 3rd modification of the conversion table of the database which concerns on 1st Embodiment.
  • (A) And (B) is a figure which shows roughly the 4th modification of the conversion table of the database which concerns on 1st Embodiment.
  • It is a figure which shows the reference table and intermediate identifier table which comprise the database of 2nd Embodiment.
  • FIG. 1 is a functional block diagram showing a schematic configuration of a database system 10 according to an embodiment of the present invention.
  • the database system 10 includes a transaction processing unit 20, a checkpoint processing unit 30, a defragmenting processing unit 31, a transaction server 32, and a storage device 40.
  • the storage device 40 stores a database 41 and a log file 42.
  • the transaction processing unit 20 includes a query reception unit 21, an analysis unit 22, a transaction execution unit 23, and a response processing unit 24.
  • the database system 10 and a plurality of client terminals 501 and 502 are connected to the network NW.
  • the network NW for example, a generally used small-scale network (for example, wired or wireless LAN) can be mentioned, but it is not particularly limited.
  • the network NW may be a large-scale network such as the Internet.
  • Each of the client terminals 501 and 502 transmits a query described in a query language (database language) such as SQL (Structured Query Language) or XQuery (XML Query Language) with respect to the database 41 to the database system 10. It has the function to do.
  • a query language database language
  • SQL Structured Query Language
  • XQuery XML Query Language
  • the hardware configuration of the database system 10 may be a general-purpose configuration.
  • a processor such as a CPU (Central Processing Unit), a main memory, a cache memory, a signal transmission bus, a timer circuit, an input device (for example, a keyboard) Or a pointing device) and an output device (for example, a display or a printer), but is not particularly limited.
  • a processor such as a CPU (Central Processing Unit), a main memory, a cache memory, a signal transmission bus, a timer circuit, an input device (for example, a keyboard) Or a pointing device) and an output device (for example, a display or a printer), but is not particularly limited.
  • a processor such as a CPU (Central Processing Unit), a main memory, a cache memory, a signal transmission bus, a timer circuit, an input device (for example, a keyboard) Or a pointing device) and an output device (for example, a display or a printer), but is not particularly limited.
  • a processor such
  • All or part of the configuration of the database system 10 may be realized by hardware, or may be realized by a computer program (or program code) that causes a processor to execute processing.
  • the processor reads the computer program from a recording medium such as a nonvolatile memory and executes it.
  • the components 21 to 24, 30, 31, 32, and 40 of the database system 10 may be incorporated into a single device, or may be incorporated in a plurality of devices that operate in cooperation with each other. Good.
  • FIG. 2 is a flowchart schematically showing a processing procedure of the transaction processing unit 20 of the database system 10.
  • the query reception unit 21 receives a query that has arrived from the client terminals 501 and 502 (step S ⁇ b> 11), and gives the received query to the analysis unit 22.
  • the analysis unit 22 executes query analysis (syntax analysis, optimization processing, etc.), and gives the analysis result to the transaction execution unit 23 (step S12).
  • the transaction execution unit 23 executes a transaction based on the analysis result for the database 41 (step S13).
  • the transaction means one unit of work including processing such as search and update of the database 41, and is called atomicity (ATOMICITY), consistency (CONSISTENCY), isolation (ISOLATION), and durability (DURABILITY). This process satisfies the ACID characteristics.
  • the transaction ends normally (YES in step S14), the transaction is committed (step S15).
  • the transaction execution unit 23 records transaction log information (history information) in the storage device 40 as a log file 42. In parallel with this, the transaction execution unit 23 records transaction log metadata (information such as the start or end of each transaction) in the transaction server 32.
  • the checkpoint processing unit 30 periodically sets checkpoints based on the metadata recorded in the transaction server 32 and the log file 42.
  • the transaction execution unit 23 executes roll forward (step S16). That is, the checkpoint processing unit 30 refers to the log file 42 and confirms the log information of the period Terr from the time of the checkpoint set immediately before to the time of failure, and is not committed during this period Terr. Log information related to the transaction is deleted from the log file 42.
  • the transaction execution unit 23 reflects the execution result of the transaction in the database 41 based on the log file 42. Thereafter, the transaction execution unit 23 returns the database 41 to the state before starting the processing of the uncommitted transaction, that is, rolls back (step S17).
  • the response processing unit 24 receives the transaction execution result from the transaction execution unit 23, and transmits the execution result to the client terminals 501 and 502 (step S18).
  • the database 41 includes an entity data group including variable-length data, and an identifier table in which a fixed-length data identifier that uniquely represents the entity data itself is stored.
  • a storage area different from the storage area assigned to the identifier table is assigned to the entity data group, and the identifier table and the entity data group are completely separated from each other.
  • the transaction execution unit 23 searches for a fixed-length data identifier in the identifier table without searching for an actual data group in response to a query request.
  • the transaction execution unit 23 executes a transaction such as an update for the database 41 using the search result.
  • the defrag processing unit 31 has a function of eliminating fragmentation of the data group. That is, when a plurality of data identifiers are distributed and stored in discontinuous storage areas in the storage device 40, the defragmentation processing unit 31 reads these data identifiers from the storage device 40, and continuously reads the identifiers for the identifier table. It has a function of writing to the storage area.
  • the defragmentation unit 31 continues the data identifiers VR11, VR12, VR13,. Can be written to the storage area.
  • FIG. 3 is a schematic diagram illustrating an example of the logical structure of the database 41 according to the first embodiment of the present invention. As shown in FIG. 3, this database structure includes an entity data group stored in the storage area DA0 in the storage device 40 and a reference table stored in a storage area different from the storage area DA0 in the storage device 40. (Identifier table) RT0.
  • the reference table RT0 has five tuples defined in the row direction and five attribute fields TID, Val1, Val2, Val3, and Val4 defined in the column direction.
  • the number of tuples in the reference table RT0 is five.
  • the number is not limited to this, and the number of tuples can be set to several tens to several millions, for example.
  • the number of attribute fields is not limited to five.
  • Unique tuple identifiers (TID) R1, R2, R3, R4, and R5 are assigned to the five tuples of the reference table RT0, respectively.
  • Data identifiers VR11, VR12,..., VR43 each having a fixed length in an area defined by these tuples and attribute fields Val1, Val2, Val3, Val4 (area where the tuples and attribute fields Val1, Val2, Val3, Val4 intersect).
  • the attribute field Val1 includes data identifiers VR11, VR12, VR13, VR14, and VR15 in areas corresponding to the tuple identifiers R1, R2, R3, R4, and R5, respectively.
  • the attribute field Val2 includes the tuple identifiers R1, R2, and R3.
  • R4, R5 include data identifiers VR21, VR22, VR23, VR23, VR24, respectively
  • attribute field Val3 includes data identifiers VR31, VR3, R4, R5, R4, R5, respectively.
  • VR32, VR33, VR34, and VR35 and attribute field Val4 includes data identifiers VR41, VR41, VR41, VR42, and VR43 in areas corresponding to tuple identifiers R1, R2, R3, R4, and R5, respectively.
  • the values of the data identifiers VR11 to VR43 can be calculated using a hash function.
  • the hash function is a logical operator that outputs a fixed-length bit string in response to a variable-length bit string input.
  • the output value (hash value) of the hash function with respect to the input of the actual data can be the values of the data identifiers VR11 to VR43, respectively.
  • the anti-collision property of the hash function (the property that it is difficult to generate the same hash value from two different input values) is sufficient depending on the scale of the database 41. High is desirable.
  • the transaction execution unit 23 converts the search character string into a hash value, searches the reference table RT0 for a data identifier having a value that matches the hash value, and stores the entity data corresponding to the found data identifier from the storage area DA0. You can find out. At this time, the transaction execution unit 23 searches the reference table RT0 including only the fixed-length data group not including the variable-length data, so that the character string can be searched at high speed.
  • the data identifiers VR11 to VR43 each have a value that uniquely represents the actual data in the storage area DA0. Therefore, the transaction execution unit 23 can search for the data identifiers VR11 to VR43 and access variable-length entity data corresponding to the data identifiers VR11 to VR43 based on the search result.
  • “substantially unique” means that the data processing uniqueness with respect to the database 41 is satisfied.
  • the database structure shown in FIG. 3 can be generated based on a set (actual table) ST of entity data as exemplified in FIG.
  • the real table ST in FIG. 4 is a 5-by-4 table having four attribute fields of “store name”, “region”, “sales”, and “year / month”. By hashing actual data such as “A store”, “B store”, “Kyushu”, etc.
  • the database of this embodiment can be generated based on an existing real table. However, the present invention is not limited to this, and the database structure of FIG. 3 of this embodiment can be directly created from input data without generating a real table. It may be generated.
  • FIG. 5 (A) to 5 (C) are diagrams showing the logical data structure constituting the database 41.
  • FIG. 5A The data structure shown in FIG. 5A has a header area at the beginning and an allocation management table at the end. In addition, an area for storing the entity data group is provided between the header area and the allocation management table.
  • FIG. 5B is a schematic diagram illustrating an example of a conversion table included in the header area.
  • This conversion table is a table that defines the correspondence between the data identifiers VR11 to VR43 and the storage areas of the entity data D11 to D43 corresponding to the data identifiers VR11 to VR43, respectively.
  • an area Fa in which position data A11 to A43 are stored.
  • an area Fai for storing position data AI11 to AI43 is provided.
  • the position data AI11 to AI43 is data indicating the position of the storage area of the tuple identifier that uniquely represents the tuple in which the data identifiers VR11 to VR43 are stored in the identifier table RT0.
  • FIG. 5C shows a metadata area Fidx in which tuple identifiers R2, R100,..., 0 corresponding to the data identifier VR11 are stored.
  • the metadata area Fidx is assigned to a storage area different from the storage area DA0.
  • the position data AI11 to AI43 is an address that specifies the absolute position of the storage area of the tuple identifier, or an offset that specifies the relative position (effective address) of the storage area with reference to a predetermined address. Good.
  • pointers indicating addresses assigned to the storage areas can be used as the position data AI11 to AI43.
  • the tuple identifier stored in the metadata area Fidx is used as index information for the identifier table RT0.
  • the transaction execution unit 23 can access not only the entity data corresponding to the data identifier by referring to the header area of FIG. 5A but also the tuple identifier associated with the entity data by referring to the metadata area Fidx. All of can be acquired.
  • By using the conversion table of FIG. 5B it is possible to collectively specify the tuple identifiers R1 to R3 from the data identifier VR41.
  • the update process of the database 41 is highly efficient In addition, it is possible to improve the processing speed of search and tabulation, and improve portability.
  • the update process can be performed efficiently.
  • the value of the variable-length entity data D41 in the storage area DA0 is updated to another value, all the values in the identifier table RT0 in FIG. 3 and the conversion table in FIG.
  • the value of the data identifier VR41 may be updated to a new value.
  • a new tuple is added to the identifier table RT0 and only existing data identifiers (for example, data identifiers VR11 to VR14) are stored in the new tuple, the conversion table of FIG. There is no need to update.
  • the database 41 is updated to the minimum necessary with the update, addition, or deletion of the entity data. Therefore, even when the database 41 is frequently updated, the update can be executed efficiently and at high speed. Is possible.
  • the database system 10 of the present embodiment uses the data structure shown in FIGS. 5A to 5C to store a set of tuple identifiers associated with the data identifier (stored in the metadata area Fidx).
  • a set of tuple identifiers stored in the identifier table RT0 can be accessed at a high speed. Therefore, it is possible to improve processing speed such as search, aggregation, and tuple update.
  • the storage area DA0 of the entity data D11 to D43 and the storage area of the data identifiers VR11 to VR43 are completely separated from each other, it is easy to distribute the reference table RT0 and the entity data group.
  • the reference table RT0 and the entity data group can be distributed and arranged in two computer systems connected via a computer network such as a LAN.
  • the storage area DA0 for the entity data D11 to D43 and the storage area for the data identifiers VR11 to VR43 are completely separated from each other, the dependency of the database structure on the hardware configuration is low, and the database structure is transferred to another system. Can be easily implanted.
  • FIG. 6A is a schematic diagram of the storage area DA0
  • FIG. 6B schematically shows a first modification of the conversion table in the storage area DA0 in the database 41 according to the first embodiment.
  • FIG. 6A is a schematic diagram of the storage area DA0
  • FIG. 6B schematically shows a first modification of the conversion table in the storage area DA0 in the database 41 according to the first embodiment.
  • an area Fid in which data identifiers VR11 to VR43 are stored and an area Fa in which position data A11 to A43 are stored are provided. It has been.
  • the position data A11 to A43 are data indicating storage areas of the entity data D11 to D43 corresponding to the data identifiers VR11 to VR43, respectively.
  • a metadata area Fidx in which a set of tuple identifiers corresponding to the data identifiers VR11 to VR43 is stored, and each area Fidx And a flag area Fn in which the number of data (flag information) stored is stored.
  • each metadata area Fidx has a fixed length, and each metadata area Fidx can store a maximum of 256 tuple identifiers.
  • the number of tuple identifiers associated with a certain data identifier exceeds the maximum number (256), in other words, the total data amount of the tuple identifier associated with the data identifier is the fixed length of the metadata area Fidx.
  • the metadata area Fidx stores position data indicating the position of a storage area (overflow area) in which 500 or more tuple identifiers are stored. For example, in the conversion table of FIG.
  • the metadata area Fidx corresponding to the data identifier VR14 stores position data AI14 indicating the position of the overflow area in which the tuple identifier is stored.
  • position data AI14 an address that specifies the absolute position of the storage area of the tuple identifier, an offset that specifies the relative position (effective address) of the storage area, or a pointer that points to an address assigned to the storage area Can be used.
  • the total length of the area Fid, the area Fa, the flag area Fn, and the metadata area Fidx can be set regardless of the number of tuple identifiers associated with each data identifier. Since it can be a fixed length, a predetermined number or less of tuple identifiers can be referred to at high speed. As a result, the access speed to the tuple set storing the common data identifier in the identifier table RT0 in FIG. 3 can be improved.
  • the number of tuple identifiers associated with a certain data identifier exceeds the maximum number (256)
  • all the tuple identifiers are stored in the overflow area, but this is not limitative. It is not a thing. In such a case, a part of the tuple identifier may be stored in the overflow area, and the remaining tuple identifier may be stored in the metadata area Fidx.
  • the flag region Fn has the maximum number of tuple identifiers instead of the multi-bit value representing the number.
  • a 1-bit value indicating that it has been exceeded may be stored as flag information.
  • FIG. 7A is a schematic diagram of the storage area DA0
  • FIG. 7B schematically shows a second modification of the conversion table in the storage area DA0 in the database 41 according to the first embodiment.
  • FIG. 7A is a schematic diagram of the storage area DA0
  • FIG. 7B schematically shows a second modification of the conversion table in the storage area DA0 in the database 41 according to the first embodiment.
  • An area Fa for storing position data A11 to A43 indicating the position of the storage area of D43 is provided.
  • the 7B further includes a fixed-length metadata area Fidx for storing a set of tuple identifiers corresponding to the data identifiers VR11 to VR43, and a flag area Fp.
  • the flag area Fp stores a value (flag information) indicating whether or not the number of data stored in each metadata area Fidx exceeds the fixed length size of the metadata area Fidx.
  • a maximum of 256 tuple identifiers can be stored in each metadata area Fidx.
  • a NULL value is stored in the flag area Fp.
  • m tuple identifiers less than the maximum number (256) are stored in the metadata area Fidx
  • the m tuple identifiers and (256-m) special identifiers are stored in the metadata area Fidx.
  • a value (eg, a zero value) is stored.
  • the flag area Fp stores position data indicating the position of the storage area (overflow area) in which the tuple identifier is stored.
  • the position data AI14 indicating the position of the overflow region in which the tuple identifier is stored is stored in the flag region Fp corresponding to the data identifier VR14.
  • 256 zero values are stored in the metadata area Fidx corresponding to the data identifier VR14.
  • the position data AI14 an address that specifies the absolute position of the storage area of the tuple identifier, an offset that specifies the relative position (effective address) of the storage area, or a pointer that points to an address assigned to the storage area Can be used.
  • the total length of the area Fid, the area Fa, the flag area Fp, and the metadata area Fidx can be set regardless of the number of tuple identifiers associated with each data identifier. Since it can be a fixed length, a predetermined number or less of tuple identifiers can be referred to at high speed. As a result, the access speed to the tuple set storing the common data identifier in the identifier table RT0 in FIG. 3 can be improved.
  • FIG. 8A is a schematic diagram of the storage area DA0
  • FIG. 8B schematically shows a third modification of the conversion table in the storage area DA0 in the database 41 according to the first embodiment.
  • FIG. 8A is a schematic diagram of the storage area DA0
  • FIG. 8B schematically shows a third modification of the conversion table in the storage area DA0 in the database 41 according to the first embodiment.
  • An area Fa for storing position data A11 to A43 indicating the position of the storage area of D43 is provided.
  • a fixed-length metadata area Fidx in which a set of tuple identifiers corresponding to the data identifiers VR11 to VR43 is stored is provided.
  • a maximum of 256 tuple identifiers can be stored in each metadata area Fidx.
  • the number of tuple identifiers associated with the data identifier exceeds the maximum number (256), in other words, the total data amount of the tuple identifier associated with the data identifier is equal to the fixed length size of the metadata area Fidx.
  • a special value for example, a value of “ ⁇ 1”
  • the value “ ⁇ 1” and the position data AI14 indicating the position of the overflow area are stored in the metadata area Fidx corresponding to the data identifier VR14.
  • the position data AI14 an address that specifies the absolute position of the storage area of the tuple identifier, an offset that specifies the relative position (effective address) of the storage area, or a pointer that points to an address assigned to the storage area can be used.
  • the entire length of the area Fid, the area Fa, and the metadata area Fidx is fixed regardless of the number of tuple identifiers associated with each data identifier. Therefore, less than a predetermined number of tuple identifiers can be referred to at high speed. As a result, the access speed to the tuple set storing the common data identifier in the identifier table RT0 in FIG. 3 can be improved.
  • the data structure of the third modified example does not have the flag area Fp, so that a simple structure can be realized.
  • the tuple identifier may be stored in an overflow area provided in advance so as to correspond to the data identifier.
  • FIG. 9A and FIG. 9B are diagrams schematically showing a logical data structure of a fourth modified example of the first embodiment.
  • the storage area DA0 is not provided with the conversion table as in the first to third modifications.
  • data blocks DB11 to DB43 corresponding to the data identifiers VR11 to VR43 of the reference table RT0 are stored in the storage area DA0.
  • Each data block includes a data identifier and a corresponding entity data value, and a set of tuple identifiers as index information.
  • FIG. 9B is a diagram schematically showing the data structure of the data block DB 22.
  • the data block DB 22 is associated with the area Fid in which the data identifier VR22 is stored, the variable length area Fd in which the actual data D22 is stored, and the data identifier VR22.
  • a variable-length area (metadata area) Fxid in which the tuple identifier group I22 is stored.
  • the area Fds is an area in which the length DL22 of the actual data D22 is stored
  • the area Fixs is an area in which the length IL22 of the metadata area Fxid is stored.
  • the transaction execution unit 23 refers to the tuple identifier associated with the entity data (data identifier) by referring to the inside of the metadata area Fxid at the end of each of the data blocks DB11 to DB43. be able to. Therefore, the database system 10 of the present embodiment can collectively acquire a set of tuple identifiers associated with the data identifier, so that the tuple set storing the common data identifier in the identifier table RT0 can be accessed at high speed. can do. Therefore, it is possible to improve processing speed such as search, aggregation, and tuple update.
  • FIG. 10 is a schematic diagram showing a database 41 according to the second embodiment of the present invention.
  • this database structure includes an entity data group stored in the storage area DA3 of the storage device 40, a reference table RT1 stored in a storage area different from the storage area DA3, and the first to first items. 3 intermediate identifier tables IT41, IT42, IT43.
  • FIG. 11A shows a schematic configuration of the reference table RT1.
  • the reference table RT1 has a plurality of tuples defined in the row direction, and four attribute fields TID, Col1Ref, Col2Ref, and Col3Ref defined in the column direction.
  • the number of tuples in the reference table RT1 can be set to several tens to several millions.
  • the number of attribute fields is not limited to four.
  • Unique tuple identifiers R1, R2, R3, R4,... are assigned to the tuples of the reference table RT1, respectively.
  • the values of the reference identifiers CRV11 to CRV31 can be calculated using the same hash function as that of the data identifier of the first embodiment. That is, the output values of the hash functions for the inputs of the data identifiers VR11 to VR31 may be the values of the reference identifiers CRV11 to CRV31, respectively.
  • FIGS. 11B to 11D are diagrams schematically showing the structures of the first to third intermediate identifier tables IT41, IT42 and IT43.
  • the first intermediate identifier table IT41 has a plurality of tuples defined in the row direction and four attribute fields Col1, Val, num, and Index defined in the column direction.
  • the attribute field Col1 includes fixed-length reference identifiers CRV11, CRV12,...,
  • the attribute field Val includes fixed-length data identifiers VR11, VR12,.
  • the attribute field Index includes a tuple identifier as index information in an area corresponding to each tuple, and the attribute field num includes the number of tuple identifiers included in the attribute field Index.
  • the second intermediate identifier table IT42 has a plurality of tuples defined in the row direction and four attribute fields Col2, Val, num, and Index defined in the column direction.
  • the attribute field Col2 includes fixed-length reference identifiers CRV21, CRV22,..., And the attribute field Val includes fixed-length data identifiers VR21, VR22,.
  • the attribute field Index includes a tuple identifier as index information in an area corresponding to each tuple, and the attribute field num includes the number of tuple identifiers included in the attribute field Index.
  • the third intermediate identifier table IT43 has a plurality of tuples defined in the row direction and four attribute fields Col3, Val, num, and Index defined in the column direction.
  • the attribute field Col3 includes fixed-length reference identifiers CRV31, CRV32,..., And the attribute field Val includes fixed-length data identifiers VR31, VR32,.
  • the attribute field Index includes a tuple identifier as index information in an area corresponding to each tuple, and the attribute field num includes the number of tuple identifiers included in the attribute field Index.
  • Each of the first to third intermediate identifier tables IT41, IT42, IT43 has a data structure from which redundancy is eliminated because reference identifiers having mutually duplicated values are excluded. Also, in the first to third intermediate identifier tables IT41 to IT43, attribute fields num and num, which correspond to the conversion table area Fn and the metadata area Fidx in FIG. 6B of the second embodiment, respectively. Index.
  • the transaction execution unit 23 searches the reference identifiers CRV11 to CRV33 and the data identifiers VR11 to VR33, and can access variable-length entity data using the search results. Since the storage area DA3 has a conversion table similar to the conversion table of the first embodiment or its modification, the transaction execution unit 23 can access the entity data based on the search result. .
  • a set of tuple identifiers associated with each of the reference identifiers CRV11 to CRV33 is integrated. Therefore, it is possible to access the tuple set storing common reference identifiers in the reference table RT1 at high speed. Therefore, it is possible to improve processing speed such as search, aggregation, and tuple update.
  • FIG. 12A to FIG. 12D are diagrams schematically showing logical data structures of modifications of the second embodiment.
  • FIG. 12A is a diagram showing a schematic configuration of the same reference table RT1 as in FIG.
  • FIGS. 12B to 12D are diagrams schematically showing the data structures of the intermediate identifier tables IT41, IT42, IT43 of this modification.
  • FIGS. 13A to 13D are diagrams schematically showing a logical data structure of another modification of the second embodiment.
  • FIG. 13A is a diagram showing a schematic configuration of the same reference table RT1 as in FIG.
  • FIGS. 13B to 13D are diagrams schematically showing the data structures of the intermediate identifier tables IT41, IT42, IT43 of the other modified examples.
  • the first to third intermediate identifier tables IT41 to IT43 of this modification each corresponds to the metadata area Fidx of the conversion table (FIG. 8B) according to the third modification of the first embodiment. It has an attribute field Index.
  • a set of tuple identifiers associated with each of the reference identifiers CRV11 to CRV33 can be acquired in a lump, so that the tuple set storing common reference identifiers in the reference table RT1 can be operated at high speed. Can be accessed. Therefore, it is possible to improve processing speed such as search, aggregation, and tuple update.
  • the embodiments of the present invention have been described with reference to the drawings. However, these are exemplifications of the present invention, and various configurations other than the above can be adopted.
  • the embodiment described above executes a process suitable for executing a transaction on the database 41, but is not limited to this.
  • the transaction is processing that satisfies the ACID characteristics, but the database structure according to the present invention can be applied to data processing that does not satisfy any of these ACID characteristics.
  • the query receiving unit 21 receives a query described in a query language
  • the analyzing unit 22 analyzes the query
  • the query may not be described in a query language (database language), but may simply include a value for calling an API (Application Programming Interface) function for the database.
  • API Application Programming Interface

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

　データベースに対するデータ更新の効率的かつ高速な実行を可能にするデータベースシステムを提供する。データベースシステムは、クエリに基づいたデータ処理をデータベースに対して実行するデータ処理部を備える。データベースは、実体データそのものを一意に表す固定長のデータ識別子が格納されている識別子テーブルと変換テーブルとを含む。変換テーブルは、実体データの記憶領域の位置を示す位置データとデータ識別子との間の対応関係を表すものである。この変換テーブルはメタデータ領域Ｆｉｄｘを有し、このメタデータ領域Ｆｉｄｘには、識別子テーブルにおいてデータ識別子が格納されているタプルを一意に表すタプル識別子が格納されている。

Description

データベースシステム、データベース管理方法、データベース構造および記憶媒体
　本発明は、データベース構造並びにデータベースに対するデータ処理を実行する技術に関する。
　ＲＤＢＭＳ（Relational DataBase Management System：リレーショナル・データベース管理システム）は、１９７０年にＥ・Ｆ・コッド（Edgar Frank Codd）により提唱された関係モデル（リレーショナルモデル）理論に基づいたシステムであり、現在広く使用されている。ＲＤＢ（Relational DataBase）は、複数のテーブル（すなわち、リレーション）の集合体であり、各テーブルは、少なくとも１つの行（タプル）と列（属性フィールド）とを有する。ＲＤＢＭＳに関する先行技術文献としては、たとえば、特許文献１（特開２００５－２０８７５７号公報）が挙げられる。
　しかしながら、一般にＲＤＢＭＳでは、データ処理量が巨大になり処理負荷が増大したときに、トランザクションの処理速度の低下が目立つようになる。この原因の１つとして、ＲＤＢを構成するテーブルを行単位で検索する際に、このテーブルの各行のデータ長が可変長である場合には、当該各行のデータ長が固定長である場合と比べて、データの読み出し位置の計算時間がかかることが挙げられる。
　また、ＲＤＢＭＳは、行ごとに一意のキー（key）を用いて行単位でデータを管理するため、行単位での大規模処理を高速かつ効率的に実行できるが、列単位での大規模処理を効率的に実行することが難しいという問題がある。たとえば、ＲＤＢＭＳは、列単位でデータ処理を実行する際、クエリが要求する列に対応する複数行のデータを読み出す必要があり、これが処理速度の低下を招くという問題がある。更に、ＲＤＢＭＳは、行単位でデータをメモリ内の連続的な記憶領域に書き込むことができるため、行単位でデータに高速にアクセスすることができる。しかしながら、ＲＤＢＭＳが、列単位での検索処理、比較演算あるいは集計演算などに関するトランザクションを実行する際には、非連続な複数のメモリ領域に格納されたデータにアクセスする現象が頻繁に生じ、これにより処理速度が低下する場合がある。
　一方、大規模な検索や集計を効率的に実行するデータベースシステムとして、データウェアハウス（ＤＷＨ：Data WareHouse）と称するシステムが使用されている。しかしながら、ＤＷＨは、基幹系業務システムとは独立して構築され、原則としてデータ更新（新規データの追加、既存データの変更または既存データの削除）を行わないシステムである。それ故、ＤＷＨは、データ更新を効率的に実行し得るデータベース構造を有していない。
　そこで、従来のＲＤＢＭＳやＤＷＨに関する前述の問題を解消することを目的として、たとえば、特許文献２（特開２０００－３３９３９０号公報）および特許文献３（国際公開第００／１０１０３号パンフレット）に開示されたシステムが提案されている。特許文献２および特許文献３のデータベースシステムは、論理的な表形式のデータを、たとえば、性別、年齢、身長および体重のそれぞれの項目に対応する複数の情報ブロックに変換することで得られるデータベース構造を利用する。各情報ブロックは、値管理テーブル（値リスト）と、この値管理テーブルへのポインタ配列とを含む。ここで、値管理テーブルへのポインタ配列とは、表形式のデータの或る列の項目値番号（すなわち値管理テーブルへのポインタ）が当該表形式のデータの所定の順番（レコード番号順）に格納された配列である。
特開２００５－２０８７５７号公報 特開２０００－３３９３９０号公報 国際公開第００／１０１０３号パンフレット
　しかしながら、特許文献２および特許文献３のデータベース構造では、データ更新（たとえば、レコードの更新、挿入または削除）の高速化のために、値管理テーブル内の項目値番号が所定の順番で配列されることが要求される。このため、データ更新の際に新たな項目値番号が値管理テーブルに挿入されると、他の既存の項目値番号を再配列する必要がある。この再配列後の項目値番号と整合するように、値管理テーブルへのポインタ配列も更新しなければならない。したがって、特許文献２および特許文献３のデータベース構造では、データ更新を効率的かつ高速に実行することができない。特に、データ更新が頻繁に行われる場合には、処理負荷が極めて大きくなり、処理速度が著しく低下するという問題がある。
　上記に鑑みて本発明の目的は、データベースに対するデータ更新の効率的かつ高速な実行を可能にするとともに検索や集計の処理速度の向上をも実現し得るデータベースシステム、データベース管理方法、データベース構造および記憶媒体を提供することである。
　本発明によれば、複数の実体データを含むデータベースを有するデータ記憶部と、クエリを受信し、当該受信されたクエリに基づいたデータ処理を前記データベースに対して実行するデータ処理部と、を備えたデータベースシステムが提供される。このデータベースシステムでは、前記データベースは、行方向に定義された少なくとも１つのタプルと列方向に定義された少なくとも１つの属性フィールドとで定まる領域に前記実体データそのものを一意に表す固定長のデータ識別子が格納されている識別子テーブルと、前記複数の実体データそれぞれの記憶領域の位置を示す位置データと前記複数のデータ識別子との間の対応関係を表す変換テーブルと、を含み、前記変換テーブルは、前記識別子テーブルにおいて前記各データ識別子が格納されている当該タプルを一意に表すタプル識別子が格納されるメタデータ領域を有する。
　本発明によれば、複数の実体データを含むデータベース構造が提供される。このデータベース構造は、行方向に定義された少なくとも１つのタプルと列方向に定義された少なくとも１つの属性フィールドとで定まる領域に前記実体データそのものを一意に表す固定長のデータ識別子が格納されている識別子テーブルと、前記複数の実体データそれぞれの記憶領域の位置を示す位置データと前記複数のデータ識別子との間の対応関係を表す変換テーブルと、を含み、前記変換テーブルは、前記識別子テーブルにおいて前記各データ識別子が格納されている当該タプルを一意に表すタプル識別子が格納されるメタデータ領域を有する。
　本発明によれば、（ａ）複数の実体データを含むデータベースについてクエリを受信するステップと、（ｂ）前記データベースに対して、当該受信されたクエリに基づいたデータ処理を実行するステップと、を備えたデータベース管理方法が提供される。このデータベース管理方法では、前記データベースは、行方向に定義された少なくとも１つのタプルと列方向に定義された少なくとも１つの属性フィールドとで定まる領域に前記実体データそのものを一意に表す固定長のデータ識別子が格納されている識別子テーブルと、前記複数の実体データそれぞれの記憶領域の位置を示す位置データと前記複数のデータ識別子との間の対応関係を表す変換テーブルと、を含み、前記変換テーブルは、前記識別子テーブルにおいて前記各データ識別子が格納されている当該タプルを一意に表すタプル識別子が格納されるメタデータ領域を有する。
　本発明によれば、コンピュータによって読み取り可能な記録媒体であって、複数の実体データを含むデータベースについてクエリを受信する処理と、前記データベースに対して当該受信されたクエリに基づいて実行されるデータ処理と、を含むデータベース管理処理を前記コンピュータに実行させるコンピュータプログラムを格納している記憶媒体が提供される。前記データベースは、行方向に定義された少なくとも１つのタプルと列方向に定義された少なくとも１つの属性フィールドとで定まる領域に前記実体データそのものを一意に表す固定長のデータ識別子が格納されている識別子テーブルと、前記複数の実体データそれぞれの記憶領域の位置を示す位置データと前記複数のデータ識別子との間の対応関係を表す変換テーブルと、を含んでいる。さらに、前記変換テーブルは、前記識別子テーブルにおいて前記各データ識別子が格納されている当該タプルを一意に表すタプル識別子が格納されるメタデータ領域を有している。
　本発明によれば、データベースに対する更新を効率的かつ高速に実行することができ、検索や集計などの処理をも高速に実行することができる。
　上述した目的、およびその他の目的、特徴および利点は、以下に述べる好適な実施の形態、およびそれに付随する以下の図面によってさらに明らかになる。
本発明に係る一実施形態のデータベースシステムの概略構成を示す機能ブロック図である。 データベースシステムのトランザクション処理部の処理手順を概略的に示すフローチャートである。 本発明の第１の実施形態に係るデータベースの論理構造の一例を示す概略図である。 実テーブルの一例を模式的に示す図である。 （Ａ）～（Ｃ）は、データベースの論理データ構造を示す図である。 （Ａ）および（Ｂ）は、第１の実施形態に係るデータベースのうちの変換テーブルの第１変形例を概略的に示す図である。 （Ａ）および（Ｂ）は、第１の実施形態に係るデータベースのうちの変換テーブルの第２変形例を概略的に示す図である。 （Ａ）および（Ｂ）は、第１の実施形態に係るデータベースのうちの変換テーブルの第３変形例を概略的に示す図である。 （Ａ）および（Ｂ）は、第１の実施形態に係るデータベースのうちの変換テーブルの第４変形例を概略的に示す図である。 本発明の第２の実施形態に係るデータベースの論理構造を示す概略図である。 第２の実施形態のデータベースを構成する参照テーブルと中間識別子テーブルとを示す図である。 第２の実施形態の変形例に係る参照テーブルと中間識別子テーブルとを示す図である。 第２の実施形態の他の変形例に係る参照テーブルと中間識別子テーブルとを示す図である。
　以下、本発明に係る実施の形態について図面を参照しつつ説明する。
　（データベースシステム１０の基本構成）
　図１は、本発明に係る一実施形態のデータベースシステム１０の概略構成を示す機能ブロック図である。このデータベースシステム１０は、トランザクション処理部２０、チェックポイント処理部３０、デフラグ処理部３１、トランザクションサーバ３２および記憶装置４０を有する。記憶装置４０には、データベース４１とログファイル４２とが格納されている。トランザクション処理部２０は、クエリ受信部２１、解析部２２、トランザクション実行部２３および応答処理部２４を含む。
　ネットワークＮＷには、データベースシステム１０と、複数のクライアント端末５０１，５０２とが接続されている。ネットワークＮＷとしては、たとえば、一般的に使用されている小規模ネットワーク（たとえば、有線または無線ＬＡＮ）が挙げられるが、特に限定されるものではない。ネットワークＮＷがインターネットなどの大規模ネットワークであってもよい。
　クライアント端末５０１，５０２は、それぞれ、データベース４１についてＳＱＬ（Structured Query Language）やＸＱｕｅｒｙ（XML Query Language：ＸＭＬ問い合わせ言語）などの問い合わせ言語（データベース言語）で記述されたクエリをデータベースシステム１０に宛てて送信する機能を有する。
　データベースシステム１０のハードウェア構成は、汎用的な構成であればよく、たとえば、ＣＰＵ（Central Processing Unit）などのプロセッサ、主メモリ、キャッシュメモリ、信号伝達用バス、タイマ回路、入力装置（たとえば、キーボードやポインティングデバイス）および出力装置（たとえば、ディスプレイやプリンタ）などのハードウェア資源によって構成され得るが、特に限定されるものではない。
　データベースシステム１０の構成の全部または一部は、ハードウェアで実現されてもよいし、あるいは、プロセッサに処理を実行させるコンピュータプログラム（またはプログラムコード）で実現されてもよい。データベースシステム１０の構成要素２１～２４，３０，３１，３２の機能がコンピュータプログラムで実現される場合、プロセッサは、不揮発性メモリなどの記録媒体からそのコンピュータプログラムを読み出し実行する。また、データベースシステム１０の構成要素２１～２４，３０，３１，３２，４０は、単一の装置に組み込まれてもよいし、あるいは、互いに連携動作する複数の装置に分散して組み込まれてもよい。
　図２は、データベースシステム１０のトランザクション処理部２０の処理手順を概略的に示すフローチャートである。トランザクション処理部２０では、クエリ受信部２１がクライアント端末５０１，５０２から到来したクエリを受信し（ステップＳ１１）、当該受信されたクエリを解析部２２に与える。解析部２２は、クエリの解析（構文解析や最適化処理など）を実行し、その解析結果をトランザクション実行部２３に与える（ステップＳ１２）。トランザクション実行部２３は、当該解析結果に基づいたトランザクションをデータベース４１に対して実行する（ステップＳ１３）。ここで、トランザクションとは、データベース４１の検索や更新などの処理を含む１つの作業単位を意味し、原子性（ATOMICITY）、一貫性（CONSISTENCY）、隔離性（ISOLATION）および持続性（DURABILITY）というＡＣＩＤ特性を満たす処理である。トランザクション処理が正常に終了したとき（ステップＳ１４のＹＥＳ）、トランザクションはコミットされる（ステップＳ１５）。
　トランザクション実行部２３は、トランザクションのログ情報（履歴情報）をログファイル４２として記憶装置４０に記録する。これと並行して、トランザクション実行部２３は、トランザクションのログのメタデータ（各トランザクションの開始または終了などの情報）をトランザクションサーバ３２に記録する。
　チェックポイント処理部３０は、トランザクションサーバ３２に記録されたメタデータとログファイル４２とに基づいて定期的にチェックポイントを設定する。トランザクションやシステムに関する障害が発生してトランザクションが正常に終了しなかったとき（図２のステップＳ１４のＮＯ）、トランザクション実行部２３は、ロールフォワードを実行する（ステップＳ１６）。すなわち、チェックポイント処理部３０は、ログファイル４２を参照して、直前に設定されたチェックポイントの時点から障害発生時点までの期間Ｔｅｒｒのログ情報を確認し、この期間Ｔｅｒｒ中にコミットされていないトランザクションに関するログ情報をログファイル４２から削除する。次に、期間Ｔｅｒｒ中にコミットされたトランザクションが存在する場合、トランザクション実行部２３は、ログファイル４２に基づいて当該トランザクションの実行結果をデータベース４１に反映させる。その後、トランザクション実行部２３は、データベース４１を、コミットされていないトランザクションの処理開始前の状態に戻す、すなわち、ロールバックする（ステップＳ１７）。
　そして、応答処理部２４は、トランザクション実行部２３からトランザクションの実行結果を受け取り、その実行結果をクライアント端末５０１，５０２に送信する（ステップＳ１８）。
　データベース４１は、後述するように、可変長データを含む実体データ群と、実体データそのものを一意に表す固定長のデータ識別子が格納されている識別子テーブルとを含む。識別子テーブルに割り当てられている記憶領域とは異なる記憶領域が実体データ群に割り当てられており、識別子テーブルと実体データ群とは互いに完全に分離されている。
　トランザクション実行部２３は、クエリの要求に応じて、実体データ群を検索せずに、識別子テーブル内の固定長のデータ識別子を検索する。トランザクション実行部２３は、この検索結果を用いて、データベース４１に対して更新などのトランザクションを実行する。
　データベース４１の更新が繰り返し実行されると、記憶装置４０内のデータの記録や削除が繰り返し実行されるので、記憶装置４０内の連続的な記憶領域に記録されていたデータ群が断片化（フラグメンテーション化）し、これによりキャッシュヒット率が低下して処理速度が低下してしまう。デフラグ処理部３１は、データ群の断片化を解消する機能を有する。すなわち、デフラグ処理部３１は、複数のデータ識別子が記憶装置４０内の不連続な記憶領域に分散して記憶されているとき、これらデータ識別子を記憶装置４０から読み出し、識別子テーブル用の連続的な記憶領域に書き込む機能を有している。たとえば、データ識別子ＶＲ１１，ＶＲ１２，ＶＲ１３，...，ＶＲ１９が互いに離れた記憶領域に記憶されているとき、デフラグ処理部３１は、これらデータ識別子ＶＲ１１，ＶＲ１２，ＶＲ１３，...，ＶＲ１９を連続した記憶領域に書き込むことができる。
　次に、本発明の種々の実施形態に係るデータベース４１の構造について説明する。
　（第１の実施形態）
　図３は、本発明の第１の実施形態に係るデータベース４１の論理構造の一例を示す概略図である。図３に示されるように、このデータベース構造は、記憶装置４０内の記憶領域ＤＡ０に格納されている実体データ群と、記憶装置４０において記憶領域ＤＡ０とは異なる記憶領域に格納されている参照テーブル（識別子テーブル）ＲＴ０とを有する。
　参照テーブルＲＴ０は、行方向に定義された５つのタプルと、列方向に定義された５つの属性フィールドＴＩＤ，Ｖａｌ１，Ｖａｌ２，Ｖａｌ３，Ｖａｌ４とを有している。第１の実施形態では、説明の便宜上、参照テーブルＲＴ０のタプルの数は５つであるが、これに限定されず、タプルの数を、たとえば、数十～数百万に設定することができる。属性フィールドの数も５つに限定されるものではない。
　参照テーブルＲＴ０の５つのタプルには、それぞれ、一意のタプル識別子（ＴＩＤ）Ｒ１，Ｒ２，Ｒ３，Ｒ４，Ｒ５が割り当てられている。これらタプルと属性フィールドＶａｌ１，Ｖａｌ２，Ｖａｌ３，Ｖａｌ４とで定まる領域（タプルと属性フィールドＶａｌ１，Ｖａｌ２，Ｖａｌ３，Ｖａｌ４とが交差する領域）にそれぞれ固定長のデータ識別子ＶＲ１１，ＶＲ１２，...，ＶＲ４３が格納されている。すなわち、属性フィールドＶａｌ１は、タプル識別子Ｒ１，Ｒ２，Ｒ３，Ｒ４，Ｒ５に対応する領域にそれぞれデータ識別子ＶＲ１１，ＶＲ１２，ＶＲ１３，ＶＲ１４，ＶＲ１５を含み、属性フィールドＶａｌ２は、タプル識別子Ｒ１，Ｒ２，Ｒ３，Ｒ４，Ｒ５に対応する領域にそれぞれデータ識別子ＶＲ２１，ＶＲ２２，ＶＲ２３，ＶＲ２３，ＶＲ２４を含み、属性フィールドＶａｌ３は、タプル識別子Ｒ１，Ｒ２，Ｒ３，Ｒ４，Ｒ５に対応する領域にそれぞれデータ識別子ＶＲ３１，ＶＲ３２，ＶＲ３３，ＶＲ３４，ＶＲ３５を含み、属性フィールドＶａｌ４は、タプル識別子Ｒ１，Ｒ２，Ｒ３，Ｒ４，Ｒ５に対応する領域にそれぞれデータ識別子ＶＲ４１，ＶＲ４１，ＶＲ４１，ＶＲ４２，ＶＲ４３を含む。
　データ識別子ＶＲ１１～ＶＲ４３の値は、ハッシュ関数を用いて算出することができる。ここで、ハッシュ関数は、可変長ビット列の入力に対して固定長のビット列を出力する論理演算子である。実体データの入力に対するハッシュ関数の出力値（ハッシュ値）をそれぞれデータ識別子ＶＲ１１～ＶＲ４３の値とすることができる。データ識別子の一意性を確保する観点からは、ハッシュ関数の対衝突性（異なる２つの入力値から同一のハッシュ値が生成されることが困難という性質）は、データベース４１の規模に応じて十分に高いことが望ましい。トランザクション実行部２３は、検索文字列をハッシュ値に変換し、このハッシュ値と一致する値を持つデータ識別子を参照テーブルＲＴ０から探し出し、探し出されたデータ識別子に対応する実体データを記憶領域ＤＡ０から探し出すことができる。このとき、トランザクション実行部２３は、可変長データを含まない固定長データ群のみからなる参照テーブルＲＴ０を検索するので、文字列を高速に探し出すことができる。
　上記データ識別子ＶＲ１１～ＶＲ４３は、記憶領域ＤＡ０内の実体データをそれぞれ実質的に一意に表す値を有する。このため、トランザクション実行部２３は、データ識別子ＶＲ１１～ＶＲ４３を検索し、その検索結果に基づいてこれらデータ識別子ＶＲ１１～ＶＲ４３に対応する可変長の実体データにアクセスすることが可能である。なお、本明細書において「実質的に一意」とは、データベース４１に対するデータ処理上の一意性を満たしていることを意味する。
　属性フィールドＶａｌ１、Ｖａｌ２、Ｖａｌ３，Ｖａｌ４の名称（属性名）としては、たとえば、「店名」、「地域」、「売上」、「年月」を設定できる。図３に示すデータベース構造は、図４に例示されるような実体データの集合（実テーブル）ＳＴに基づいて生成することができる。図４の実テーブルＳＴは、「店名」、「地域」、「売上」、「年月」という４つの属性フィールドを有する５行４列のテーブルである。この実テーブルＳＴの「Ａ店」、「Ｂ店」、「九州」などの実体データをハッシュ化（実体データの値をハッシュ値に変換）し、実体データを記憶領域ＤＡ０に格納することで、図３に示した固定長のデータ識別子ＶＲ１１，ＶＲ１２，...，ＶＲ４３を生成することができる。なお、本実施形態のデータベースを既存の実テーブルに基づいて生成することができるが、これに限らず、実テーブルを生成せずに入力データから、直接、本実施形態の図３のデータベース構造を生成してもよい。
　図５（Ａ）～図５（Ｃ）は、データベース４１を構成する論理データ構造を示す図である。図５（Ａ）に示されるデータ構造は、先頭部分にヘッダ領域を有し、末尾部分にアロケーション管理テーブルを有している。また、ヘッダ領域とアロケーション管理テーブルとの間に実体データ群が格納される領域が設けられている。
　図５（Ｂ）は、ヘッダ領域に含まれる変換テーブルの一例を示す概略図である。この変換テーブルは、データ識別子ＶＲ１１～ＶＲ４３と、これらデータ識別子ＶＲ１１～ＶＲ４３それぞれに対応する実体データＤ１１～Ｄ４３の記憶領域との間の対応関係を規定するテーブルである。この変換テーブルにおいては、図５（Ｂ）に示されるように、データ識別子ＶＲ１１～ＶＲ４３が格納される領域Ｆｉｄと、これらデータ識別子ＶＲ１１～ＶＲ４３それぞれに対応する実体データＤ１１～Ｄ４３の記憶領域の位置を示す位置データＡ１１～Ａ４３が格納される領域Ｆａとが設けられている。更に、位置データＡＩ１１～ＡＩ４３が格納される領域Ｆａｉが設けられている。位置データＡＩ１１～ＡＩ４３は、識別子テーブルＲＴ０においてデータ識別子ＶＲ１１～ＶＲ４３が格納されているタプルを一意に表すタプル識別子の記憶領域の位置を示すデータである。図５（Ｃ）は、データ識別子ＶＲ１１に対応するタプル識別子Ｒ２，Ｒ１００，...，０が格納されているメタデータ領域Ｆｉｄｘを示す図である。メタデータ領域Ｆｉｄｘは、記憶領域ＤＡ０とは異なる記憶領域に割り当てられている。
　ここで、位置データＡＩ１１～ＡＩ４３は、タプル識別子の当該記憶領域の絶対的位置を指定するアドレス、もしくは、所定アドレスを基準として当該記憶領域の相対的位置（実効アドレス）を指定するオフセットであればよい。あるいは、当該記憶領域に割り当てられたアドレスを指すポインタを位置データＡＩ１１～ＡＩ４３として使用することもできる。
　図５（Ｂ）の変換テーブルでは、同一値を有するデータ識別子の重複が排除されている（すなわち、変換テーブル内にある任意の２つのデータ識別子の値は必ず異なる）ので、この変換テーブルを使用することにより、同一値を有する実体データを重複させずに記憶領域ＤＡ０に記憶させることができる。言い換えれば、データベース４１を構成する実体データ群を圧縮して記憶領域ＤＡ０に記憶させることができるので、記憶領域ＤＡ０の効率的な利用が可能となる。後述する第１～第４変形例の変換テーブルについても同様である。
　メタデータ領域Ｆｉｄｘに格納されたタプル識別子は、識別子テーブルＲＴ０に対するインデックス情報として利用される。トランザクション実行部２３は、図５（Ａ）のヘッダ領域を参照することによりデータ識別子に対応する実体データにアクセスできるだけでなく、メタデータ領域Ｆｉｄｘを参照することにより、実体データに関連付けられたタプル識別子の全てを取得することができる。言い換えれば、データ識別子から、識別子テーブルＲＴ０において当該データ識別子が格納されているタプルの集合を特定することが可能である。たとえば、図３に示されるように、データ識別子ＶＲ４１が格納されているタプルには、複数のタプル識別子Ｒ１～Ｒ３が割り当てられている。図５（Ｂ）の変換テーブルを使用することで、データ識別子ＶＲ４１からタプル識別子Ｒ１～Ｒ３を一括して特定することが可能である。
　本実施形態のデータベースシステム１０が奏する効果は以下の通りである。
　実体データＤ１１～Ｄ４３の記憶領域ＤＡ０と、これら実体データＤ１１～Ｄ４３をそれぞれ一意に表すデータ識別子ＶＲ１１～ＶＲ４３の記憶領域とは互いに完全に分離されているので、データベース４１の更新処理の高効率化、検索や集計の処理速度の向上、並びに移植性の向上を実現することができる。
　具体的には、データベース４１が更新、追加または削除されるとき、更新処理を効率的に行うことができる。たとえば、記憶領域ＤＡ０内の可変長の実体データＤ４１の値を別の値に更新する場合、この更新に合わせて、図３の識別子テーブルＲＴ０内および図５（Ｂ）の変換テーブル内の全てのデータ識別子ＶＲ４１の値を新たな値に更新すればよい。また、新たなタプルを識別子テーブルＲＴ０に追加する場合であって、この新たなタプルに既存のデータ識別子（たとえば、データ識別子ＶＲ１１～ＶＲ１４）しか格納されない場合は、図５（Ｂ）の変換テーブルを更新する必要はない。さらに、識別子テーブルＲＴ０からタプルの一部（たとえば、タプル識別子Ｒ１のタプル）を削除する場合に、必ずしも、図５（Ｂ）の変換テーブルを更新する必要はない。このように実体データの更新、追加または削除に伴い、データベース４１は必要最小限に更新されるので、データベース４１に対する更新が頻繁に行われる場合でも、かかる更新を効率的かつ高速に実行することが可能である。
　また、本実施形態のデータベースシステム１０は、図５（Ａ）～図５（Ｃ）に示したデータ構造を使用して、データ識別子に関連付けられているタプル識別子の集合（メタデータ領域Ｆｉｄｘに格納されているタプル識別子の集合）を一括して取得することができるので、識別子テーブルＲＴ０において共通のデータ識別子を格納するタプル集合に高速にアクセスすることができる。よって、検索や集計やタプルの更新などの処理速度の向上が可能である。
　実体データＤ１１～Ｄ４３の記憶領域ＤＡ０とデータ識別子ＶＲ１１～ＶＲ４３の記憶領域とは互いに完全に分離されているので、参照テーブルＲＴ０と実体データ群とを分散配置することが容易である。たとえば、ＬＡＮなどのコンピュータネットワークを介して接続された２つのコンピュータシステムにそれぞれ参照テーブルＲＴ０と実体データ群とを分散配置することができる。
　さらに、実体データＤ１１～Ｄ４３の記憶領域ＤＡ０とデータ識別子ＶＲ１１～ＶＲ４３の記憶領域とは互いに完全に分離されているので、データベース構造のハードウェア構成への依存性は低く、データベース構造を他のシステムへ容易に移植することができる。
　（第１の実施形態の第１変形例）
　図６（Ａ）は、記憶領域ＤＡ０の模式図であり、図６（Ｂ）は、第１の実施形態に係るデータベース４１のうち記憶領域ＤＡ０内の変換テーブルの第１変形例を概略的に示す図である。
　図６（Ｂ）の変換テーブルには、図５（Ｂ）の変換テーブルと同様に、データ識別子ＶＲ１１～ＶＲ４３が格納される領域Ｆｉｄと、位置データＡ１１～Ａ４３が格納される領域Ｆａとが設けられている。位置データＡ１１～Ａ４３は、データ識別子ＶＲ１１～ＶＲ４３それぞれに対応する実体データＤ１１～Ｄ４３の記憶領域を示すデータである。
　図６（Ｂ）の変換テーブルには、更に、データ識別子ＶＲ１１～ＶＲ４３の各々に対して、データ識別子ＶＲ１１～ＶＲ４３にそれぞれ対応するタプル識別子の集合が格納されるメタデータ領域Ｆｉｄｘと、各領域Ｆｉｄｘに格納されているデータの個数（フラグ情報）が格納されているフラグ領域Ｆｎとが設けられている。
　第１変形例では、各メタデータ領域Ｆｉｄｘは固定長であり、各メタデータ領域Ｆｉｄｘには、最大２５６個のタプル識別子を格納することができる。或るデータ識別子に関連付けられたタプル識別子の個数が最大個数（２５６個）を超えた場合、言い換えれば、当該データ識別子に関連付けられたタプル識別子の全体のデータ量がそのメタデータ領域Ｆｉｄｘの固定長サイズを超えた場合には、当該メタデータ領域Ｆｉｄｘには、５００個以上のタプル識別子が格納されている記憶領域（オーバフロー領域）の位置を示す位置データが格納される。たとえば、図６（Ｂ）の変換テーブルでは、データ識別子ＶＲ１４に対応するメタデータ領域Ｆｉｄｘには、タプル識別子が格納されているオーバフロー領域の位置を示す位置データＡＩ１４が格納される。位置データＡＩ１４としては、タプル識別子の当該記憶領域の絶対的位置を指定するアドレス、当該記憶領域の相対的位置（実効アドレス）を指定するオフセット、あるいは、当該記憶領域に割り当てられたアドレスを指すポインタを使用すればよい。
　図６（Ｂ）に示す変換テーブルを使用することで、各データ識別子に関連付けられたタプル識別子の個数に関係なく、領域Ｆｉｄ、領域Ｆａ、フラグ領域Ｆｎおよびメタデータ領域Ｆｉｄｘの全体の長さを固定長にすることができるので、所定個数以下のタプル識別子を高速に参照することができる。これにより、図３の識別子テーブルＲＴ０において共通のデータ識別子を格納するタプル集合へのアクセス速度の向上が可能となる。
　なお、本実施形態では、或るデータ識別子に関連付けられたタプル識別子の個数が最大個数（２５６個）を超えた場合、当該タプル識別子の全てがオーバフロー領域に格納されるが、これに限定されるものではない。かかる場合に当該タプル識別子の一部をオーバフロー領域に格納してもよく、残るタプル識別子をメタデータ領域Ｆｉｄｘに格納してもよい。
　また、データ識別子に関連付けられたタプル識別子の個数が最大個数（２５６個）を超えた場合に、フラグ領域Ｆｎには、その個数を表す多ビット値の代わりに、タプル識別子の個数が最大個数を超えたことを示す１ビット値がフラグ情報として格納されてもよい。
　（第１の実施形態の第２変形例）
　図７（Ａ）は、記憶領域ＤＡ０の模式図であり、図７（Ｂ）は、第１の実施形態に係るデータベース４１のうち記憶領域ＤＡ０内の変換テーブルの第２変形例を概略的に示す図である。
　図７（Ｂ）の変換テーブルには、図５（Ｂ）の変換テーブルと同様に、データ識別子ＶＲ１１～ＶＲ４３が格納される領域Ｆｉｄと、これらデータ識別子ＶＲ１１～ＶＲ４３それぞれに対応する実体データＤ１１～Ｄ４３の記憶領域の位置を示す位置データＡ１１～Ａ４３が格納される領域Ｆａとが設けられている。
　図７（Ｂ）の変換テーブルには、更に、データ識別子ＶＲ１１～ＶＲ４３にそれぞれ対応するタプル識別子の集合が格納される固定長のメタデータ領域Ｆｉｄｘと、フラグ領域Ｆｐとが設けられている。フラグ領域Ｆｐには、各メタデータ領域Ｆｉｄｘに格納されているデータの個数がメタデータ領域Ｆｉｄｘの固定長サイズを超えたか否かを示す値（フラグ情報）が格納されている。
　第２変形例では、各メタデータ領域Ｆｉｄｘには、たとえば、最大２５６個のタプル識別子を格納することができる。或るデータ識別子に関連付けられたタプル識別子の個数が最大個数（２５６個）以下の場合、フラグ領域ＦｐにはＮＵＬＬ値が格納される。また、メタデータ領域Ｆｉｄｘに最大個数（２５６個）未満のｍ個のタプル識別子が格納される場合、このメタデータ領域Ｆｉｄｘには、これらｍ個のタプル識別子と、（２５６－ｍ）個の特殊値（たとえば、ゼロの値）とが格納される。たとえば、図７（Ｂ）の変換テーブルを参照すると、データ識別子ＶＲ１３に対応するメタデータ領域Ｆｉｄｘには、３個のタプル識別子Ｒ３，Ｒ１５，Ｒ２５が格納されるとともに、２５３（＝２５６－３）個のゼロ値（＝０）が格納されている。
　一方、データ識別子に関連付けられたタプル識別子の個数が最大個数（２５６個）を超えた場合、言い換えれば、当該データ識別子に関連付けられたタプル識別子の全体のデータ量がそのメタデータ領域Ｆｉｄｘの固定長サイズを超えた場合には、フラグ領域Ｆｐには、タプル識別子が格納されている記憶領域（オーバフロー領域）の位置を示す位置データが格納される。たとえば、図７（Ｂ）の変換テーブルでは、データ識別子ＶＲ１４に対応するフラグ領域Ｆｐには、タプル識別子が格納されているオーバフロー領域の位置を示す位置データＡＩ１４が格納されている。また、このデータ識別子ＶＲ１４に対応するメタデータ領域Ｆｉｄｘには、２５６個のゼロ値（＝０）が格納されている。位置データＡＩ１４としては、タプル識別子の当該記憶領域の絶対的位置を指定するアドレス、当該記憶領域の相対的位置（実効アドレス）を指定するオフセット、あるいは、当該記憶領域に割り当てられたアドレスを指すポインタを使用すればよい。
　図７（Ｂ）に示す変換テーブルを使用することで、各データ識別子に関連付けられたタプル識別子の個数に関係なく、領域Ｆｉｄ、領域Ｆａ、フラグ領域Ｆｐおよびメタデータ領域Ｆｉｄｘの全体の長さを固定長にすることができるので、所定個数以下のタプル識別子を高速に参照することができる。これにより、図３の識別子テーブルＲＴ０において共通のデータ識別子を格納するタプル集合へのアクセス速度の向上が可能となる。
　（第１の実施形態の第３変形例）
　図８（Ａ）は、記憶領域ＤＡ０の模式図であり、図８（Ｂ）は、第１の実施形態に係るデータベース４１のうち記憶領域ＤＡ０内の変換テーブルの第３変形例を概略的に示す図である。
　図８（Ｂ）の変換テーブルには、図５（Ｂ）の変換テーブルと同様に、データ識別子ＶＲ１１～ＶＲ４３が格納される領域Ｆｉｄと、これらデータ識別子ＶＲ１１～ＶＲ４３それぞれに対応する実体データＤ１１～Ｄ４３の記憶領域の位置を示す位置データＡ１１～Ａ４３が格納される領域Ｆａとが設けられている。更に、データ識別子ＶＲ１１～ＶＲ４３にそれぞれ対応するタプル識別子の集合が格納される固定長のメタデータ領域Ｆｉｄｘが設けられている。
　第３変形例では、各メタデータ領域Ｆｉｄｘには、たとえば、最大２５６個のタプル識別子を格納することができる。データ識別子に関連付けられたタプル識別子の個数が最大個数（２５６個）を超えた場合、言い換えれば、当該データ識別子に関連付けられたタプル識別子の全体のデータ量がそのメタデータ領域Ｆｉｄｘの固定長サイズを超えた場合には、当該メタデータ領域Ｆｉｄｘには、特殊値（たとえば「－１」の値）と、タプル識別子が格納されている記憶領域（オーバフロー領域）の位置を示す位置データとが格納される。
　たとえば、図８（Ｂ）の変換テーブルでは、データ識別子ＶＲ１４に対応するメタデータ領域Ｆｉｄｘには、「－１」の値と、オーバフロー領域の位置を示す位置データＡＩ１４とが格納されている。位置データＡＩ１４としては、タプル識別子の当該記憶領域の絶対的位置を指定するアドレス、当該記憶領域の相対的位置（実効アドレス）を指定するオフセット、あるいは、当該記憶領域に割り当てられたアドレスを指すポインタを使用すればよい。
　図８（Ｂ）に示す変換テーブルを使用することで、各データ識別子に関連付けられたタプル識別子の個数に関係なく、領域Ｆｉｄ、領域Ｆａおよびメタデータ領域Ｆｉｄｘの全体の長さを固定長にすることができるので、所定個数未満のタプル識別子を高速に参照することができる。これにより、図３の識別子テーブルＲＴ０において共通のデータ識別子を格納するタプル集合へのアクセス速度の向上が可能となる。また、第２変形例の図７のデータ構造と比べると、第３変形例のデータ構造は、フラグ領域Ｆｐを持たないので、シンプルな構造を実現することが可能である。
　データ識別子に関連付けられたタプル識別子の個数が最大個数（２５６個）を超えた場合に、当該メタデータ領域Ｆｉｄｘに「－１」の値と位置データの両方を格納する代わりに、「－１」の値を格納してもよい。この場合、当該データ識別子に対応するように予め設けられたオーバフロー領域に当該タプル識別子を格納すればよい。
　（第１の実施形態の第４変形例）
　図９（Ａ）および図９（Ｂ）は、第１の実施形態の第４変形例の論理データ構造を概略的に示す図である。第４変形例では、記憶領域ＤＡ０には、上記第１～第３変形例のような変換テーブルは設けられていない。図９（Ａ）に示されるように、本変形例では、記憶領域ＤＡ０には、参照テーブルＲＴ０のデータ識別子ＶＲ１１～ＶＲ４３にそれぞれ対応するデータブロックＤＢ１１～ＤＢ４３が格納されている。各データブロックは、データ識別子とこれに対応する実体データ値とを含むとともに、インデックス情報としてのタプル識別子の集合を含む。
　図９（Ｂ）は、データブロックＤＢ２２のデータ構造を概略的に示す図である。図９（Ｂ）に示されているように、データブロックＤＢ２２は、データ識別子ＶＲ２２が格納される領域Ｆｉｄと、実体データＤ２２が格納される可変長領域Ｆｄと、データ識別子ＶＲ２２に関連付けされているタプル識別子群Ｉ２２が格納される可変長領域（メタデータ領域）Ｆｘｉｄとを有する。また、データブロックＤＢ２２において、領域Ｆｄｓは、実体データＤ２２の長さＤＬ２２が格納される領域であり、領域Ｆｉｘｓは、メタデータ領域Ｆｘｉｄの長さＩＬ２２が格納される領域である。
　本変形例によれば、トランザクション実行部２３は、データブロックＤＢ１１～ＤＢ４３の各々の末尾部分のメタデータ領域Ｆｘｉｄ内を参照して、実体データ（データ識別子）に関連付けられているタプル識別子を参照することができる。したがって、本実施形態のデータベースシステム１０は、データ識別子に関連付けられているタプル識別子の集合を一括して取得することができるので、識別子テーブルＲＴ０において共通のデータ識別子を格納するタプル集合に高速にアクセスすることができる。よって、検索や集計やタプルの更新などの処理速度の向上が可能である。
　（第２の実施形態）
　図１０は、本発明の第２の実施形態に係るデータベース４１を示す概略図である。図１０に示されるように、このデータベース構造は、記憶装置４０の記憶領域ＤＡ３に格納された実体データ群と、記憶領域ＤＡ３とは別の記憶領域に格納された参照テーブルＲＴ１および第１～第３の中間識別子テーブルＩＴ４１，ＩＴ４２，ＩＴ４３とを有する。
　図１１（Ａ）は、参照テーブルＲＴ１の概略構成を示す図である。参照テーブルＲＴ１は、行方向に定義された複数のタプルと、列方向に定義された４つの属性フィールドＴＩＤ，Ｃｏｌ１Ｒｅｆ，Ｃｏｌ２Ｒｅｆ，Ｃｏｌ３Ｒｅｆとを有している。参照テーブルＲＴ１のタプルの数については、たとえば、これを数十～数百万に設定することができる。属性フィールドの数も４つに限定されるものではない。
　参照テーブルＲＴ１のタプルには、それぞれ、一意のタプル識別子（ＴＩＤ）Ｒ１，Ｒ２，Ｒ３，Ｒ４，...が割り当てられている。これらタプルと属性フィールドＣｏｌ１Ｒｅｆ，Ｃｏｌ２Ｒｅｆ，Ｃｏｌ３Ｒｅｆとで定まる領域（タプルと属性フィールドＣｏｌ１Ｒｅｆ，Ｃｏｌ２Ｒｅｆ，Ｃｏｌ３Ｒｅｆとが交差する領域）にそれぞれ固定長の参照識別子ＣＲＶ１１，ＣＲＶ１２，...，ＣＲＶ３１，...が格納されている。参照識別子ＣＲＶ１１～ＣＲＶ３１の値は、上記第１の実施形態のデータ識別子の場合と同様のハッシュ関数を用いて算出することができる。すなわち、データ識別子ＶＲ１１～ＶＲ３１の入力に対するハッシュ関数の出力値をそれぞれ参照識別子ＣＲＶ１１～ＣＲＶ３１の値とすればよい。
　図１１（Ｂ）～図１１（Ｄ）は、第１～第３の中間識別子テーブルＩＴ４１，ＩＴ４２，ＩＴ４３の構造を概略的に示す図である。第１の中間識別子テーブルＩＴ４１は、行方向に定義された複数のタプルと、列方向に定義された４つの属性フィールドＣｏｌ１，Ｖａｌ，ｎｕｍ，Ｉｎｄｅｘとを有する。属性フィールドＣｏｌ１は、固定長の参照識別子ＣＲＶ１１，ＣＲＶ１２，...を含み、属性フィールドＶａｌは、タプルにそれぞれ対応する領域にそれぞれ固定長のデータ識別子ＶＲ１１，ＶＲ１２，...を含む。属性フィールドＩｎｄｅｘは、タプルにそれぞれ対応する領域に、インデックス情報としてのタプル識別子を含み、属性フィールドｎｕｍは、属性フィールドＩｎｄｅｘ内に含まれるタプル識別子の個数を含む。
　第２の中間識別子テーブルＩＴ４２は、行方向に定義された複数のタプルと、列方向に定義された４つの属性フィールドＣｏｌ２，Ｖａｌ，ｎｕｍ，Ｉｎｄｅｘとを有する。属性フィールドＣｏｌ２は、固定長の参照識別子ＣＲＶ２１，ＣＲＶ２２，...を含み、属性フィールドＶａｌは、タプルにそれぞれ対応する領域にそれぞれ固定長のデータ識別子ＶＲ２１，ＶＲ２２，...を含む。属性フィールドＩｎｄｅｘは、タプルにそれぞれ対応する領域に、インデックス情報としてのタプル識別子を含み、属性フィールドｎｕｍは、属性フィールドＩｎｄｅｘ内に含まれるタプル識別子の個数を含む。
　そして、第３の中間識別子テーブルＩＴ４３は、行方向に定義された複数のタプルと、列方向に定義された４つの属性フィールドＣｏｌ３，Ｖａｌ，ｎｕｍ，Ｉｎｄｅｘとを有する。属性フィールドＣｏｌ３は、固定長の参照識別子ＣＲＶ３１，ＣＲＶ３２，...を含み、属性フィールドＶａｌは、タプルにそれぞれ対応する領域にそれぞれ固定長のデータ識別子ＶＲ３１，ＶＲ３２，...を含む。属性フィールドＩｎｄｅｘは、タプルにそれぞれ対応する領域に、インデックス情報としてのタプル識別子を含み、属性フィールドｎｕｍは、属性フィールドＩｎｄｅｘ内に含まれるタプル識別子の個数を含む。
　第１～第３の中間識別子テーブルＩＴ４１，ＩＴ４２，ＩＴ４３の各々は、互いに重複した値を持つ参照識別子を排除しているので、冗長性を排除したデータ構造を有する。また、第１～第３の中間識別子テーブルＩＴ４１～ＩＴ４３においては、それぞれ、上記第２の実施形態の図６（Ｂ）の変換テーブルの領域Ｆｎとメタデータ領域Ｆｉｄｘとに相当する属性フィールドｎｕｍ，Ｉｎｄｅｘを有している。
　トランザクション実行部２３は、参照識別子ＣＲＶ１１～ＣＲＶ３３およびデータ識別子ＶＲ１１～ＶＲ３３を検索し、この検索結果を用いて可変長の実体データにアクセスすることができる。記憶領域ＤＡ３は、上記第１の実施形態あるいはその変形例の変換テーブルと同様の変換テーブルを有しているので、トランザクション実行部２３は、当該検索結果に基づいて実体データにアクセスすることができる。
　また、本実施形態では、第１～第３の中間識別子テーブルＩＴ４１～ＩＴ４３の属性フィールドｎｕｍ，Ｉｎｄｅｘを使用することにより、参照識別子ＣＲＶ１１～ＣＲＶ３３の各々に関連付けられているタプル識別子の集合を一括して取得することができるので、参照テーブルＲＴ１において共通の参照識別子を格納するタプル集合に高速にアクセスすることができる。よって、検索や集計やタプルの更新などの処理速度の向上が可能である。
　（第２の実施形態の変形例）
　図１２（Ａ）～図１２（Ｄ）は、第２の実施形態の変形例の論理データ構造を概略的に示す図である。図１２（Ａ）は、図１１（Ａ）と同じ参照テーブルＲＴ１の概略構成を示す図である。また、図１２（Ｂ）～図１２（Ｄ）は、この変形例の中間識別子テーブルＩＴ４１，ＩＴ４２，ＩＴ４３のデータ構造を概略的に示す図である。本変形例の第１～第３の中間識別子テーブルＩＴ４１～ＩＴ４３においては、それぞれ、上記第１の実施形態の第２変形例に係る変換テーブル（図７（Ｂ））の領域Ｆｐとメタデータ領域Ｆｉｄｘとに相当する属性フィールドＯｖｅｒ，Ｉｎｄｅｘを有している。
　また、図１３（Ａ）～図１３（Ｄ）は、第２の実施形態の他の変形例の論理データ構造を概略的に示す図である。図１３（Ａ）は、図１１（Ａ）と同じ参照テーブルＲＴ１の概略構成を示す図である。また、図１３（Ｂ）～図１３（Ｄ）は、当該他の変形例の中間識別子テーブルＩＴ４１，ＩＴ４２，ＩＴ４３のデータ構造を概略的に示す図である。本変形例の第１～第３の中間識別子テーブルＩＴ４１～ＩＴ４３においては、それぞれ、上記第１の実施形態の第３変形例に係る変換テーブル（図８（Ｂ））のメタデータ領域Ｆｉｄｘに相当する属性フィールドＩｎｄｅｘを有している。
　したがって、これら変形例においても、参照識別子ＣＲＶ１１～ＣＲＶ３３の各々に関連付けられているタプル識別子の集合を一括して取得することができるので、参照テーブルＲＴ１において共通の参照識別子を格納するタプル集合に高速にアクセスすることができる。したがって、検索や集計やタプルの更新などの処理速度の向上が可能である。
　以上、図面を参照して本発明の実施形態について述べたが、これらは本発明の例示であり、上記以外の様々な構成を採用することもできる。たとえば、上記実施形態は、データベース４１に対してトランザクションを実行するために適した処理を実行するが、これに限定されるものではない。上述の通り、トランザクションは、ＡＣＩＤ特性を満たす処理であるが、本発明に係るデータベース構造は、これらＡＣＩＤ特性のうちのいずれかの特性を満たさないデータ処理にも適用することが可能である。
　上記実施形態では、クエリ受信部２１は問い合わせ言語で記述されたクエリを受信し、解析部２２はそのクエリを解析するが、これに限定されるものではない。たとえば、クエリが、問い合わせ言語（データベース言語）で記述されておらず、単に、データベース用のＡＰＩ（Application Programming Interface）関数を呼び出すための値を含むものであってもよい。
　この出願は、日本国特許庁に出願された特願２００９－１４１４２号（出願日：２００９年１月２６日）を基礎とする優先権を主張するものであり、その開示の全ては、本明細書の一部として援用（incorporation herein by reference）される。

Claims (29)

  1. 　複数の実体データを含むデータベースを有するデータ記憶部と、
    　クエリを受信し、当該受信されたクエリに基づいたデータ処理を前記データベースに対して実行するデータ処理部と、
    を備え、
    　前記データベースは、
    　行方向に定義された少なくとも１つのタプルと列方向に定義された少なくとも１つの属性フィールドとで定まる領域に前記実体データそのものを一意に表す固定長のデータ識別子が格納されている識別子テーブルと、
    　前記複数の実体データそれぞれの記憶領域の位置を示す位置データと前記複数のデータ識別子との間の対応関係を表す変換テーブルと、
    を含み、
    　前記変換テーブルは、前記識別子テーブルにおいて前記各データ識別子が格納されている当該タプルを一意に表すタプル識別子が格納されるメタデータ領域を有する、データベースシステム。
  2. 　請求項１記載のデータベースシステムであって、前記識別子テーブルに割り当てられた記憶領域と前記実体データに割り当てられた記憶領域とが互いに異なる、データベースシステム。
  3. 　請求項１または２記載のデータベースシステムであって、前記データ識別子の値は、前記実体データの入力に対して固定長のビット列を出力するハッシュ関数の出力値である、データベースシステム。
  4. 　請求項１から３のうちのいずれか１項に記載のデータベースシステムであって、前記メタデータ領域のサイズは固定長である、データベースシステム。
  5. 　請求項４に記載のデータベースシステムであって、前記変換テーブルは、前記各データ識別子に対して、前記タプル識別子のデータ量が前記メタデータ領域の固定長サイズを超えたか否かを示すフラグ情報が格納されるフラグ領域を有する、データベースシステム。
  6. 　請求項４または５に記載のデータベースシステムであって、
    　前記データベースは、前記タプル識別子のデータ量が前記固定長サイズを超えるときに当該タプル識別子の全部または一部が格納されるオーバフロー領域を更に有し、
    　前記データ処理部は、前記タプル識別子のデータ量が前記固定長サイズを超えるときに、当該タプル識別子の全部または一部を前記オーバフロー領域に格納する、データベースシステム。
  7. 　請求項６に記載のデータベースシステムであって、前記データ処理部は、前記オーバフロー領域に前記タプル識別子を格納するとき、当該タプル識別子の記憶領域の位置を示す位置データを前記メタデータ領域に格納する、データベースシステム。
  8. 　請求項７に記載のデータベースシステムであって、前記タプル識別子の記憶領域の位置を示す位置データは、前記タプル識別子の記憶領域の絶対的位置を指定するアドレスである、データベースシステム。
  9. 　請求項７に記載のデータベースシステムであって、前記タプル識別子の記録領域の位置を示す位置データは、前記タプル識別子の記憶領域の相対的位置を指定するオフセットである、データベースシステム。
  10. 　請求項１から９のうちのいずれか１項に記載のデータベースシステムであって、前記複数の実体データは可変長データを含む、データベースシステム。
  11. 　請求項１から１０のうちのいずれか１項に記載のデータベースシステムであって、
    　前記識別子テーブルは複数存在し、
    　前記データベースは、前記複数の識別子テーブル内のデータ識別子をそれぞれ一意に表す参照識別子の集合を有する参照テーブルを更に含み、
    　前記データ処理部は、前記参照テーブルおよび前記識別子テーブルを用いて前記データ処理を実行する、データベースシステム。
  12. 　請求項１から１１のうちのいずれか１項に記載のデータベースシステムであって、
    　前記クエリは、問い合わせ言語で記述されており、
    　前記データ処理部は、前記クエリを解析し、その解析結果に基づいたトランザクションを前記データ処理として前記データベースに対して実行する、データベースシステム。
  13. 　複数の実体データを含むデータベース構造であって、
    　行方向に定義された少なくとも１つのタプルと列方向に定義された少なくとも１つの属性フィールドとで定まる領域に前記実体データそのものを一意に表す固定長のデータ識別子が格納されている識別子テーブルと、
    　前記複数の実体データそれぞれの記憶領域の位置を示す位置データと前記複数のデータ識別子との間の対応関係を表す変換テーブルと、
    を含み、
    　前記変換テーブルは、前記識別子テーブルにおいて前記各データ識別子が格納されている当該タプルを一意に表すタプル識別子が格納されるメタデータ領域を有する、データベース構造。
  14. 　請求項１３記載のデータベース構造であって、前記識別子テーブルに割り当てられた記憶領域と前記実体データに割り当てられた記憶領域とが互いに異なる、データベース構造。
  15. 　請求項１３または１４に記載のデータベース構造であって、前記メタデータ領域のサイズは固定長である、データベース構造。
  16. 　請求項１５に記載のデータベース構造であって、前記変換テーブルは、前記各データ識別子に対して、前記タプル識別子のデータ量が前記メタデータ領域の固定長サイズを超えたか否かを示すフラグ情報が格納されるフラグ領域を有する、データベース構造。
  17. 　請求項１５または１６に記載のデータベース構造であって、前記タプル識別子のデータ量が前記固定長サイズを超えるときに当該タプル識別子の全部または一部が格納されるオーバフロー領域を更に有するデータベース構造。
  18. 　（ａ）複数の実体データを含むデータベースについてクエリを受信するステップと、
    　（ｂ）前記データベースに対して、当該受信されたクエリに基づいたデータ処理を実行するステップと、
    を備え、
    　前記データベースは、
    　行方向に定義された少なくとも１つのタプルと列方向に定義された少なくとも１つの属性フィールドとで定まる領域に前記実体データそのものを一意に表す固定長のデータ識別子が格納されている識別子テーブルと、
    　前記複数の実体データそれぞれの記憶領域の位置を示す位置データと前記複数のデータ識別子との間の対応関係を表す変換テーブルと、
    を含み、
    　前記変換テーブルは、前記識別子テーブルにおいて前記各データ識別子が格納されている当該タプルを一意に表すタプル識別子が格納されるメタデータ領域を有する、データベース管理方法。
  19. 　請求項１８記載のデータベース管理方法であって、前記識別子テーブルに割り当てられた記憶領域と前記実体データに割り当てられた記憶領域とが互いに異なる、データベース管理方法。
  20. 　請求項１８または１９に記載のデータベース管理方法であって、前記メタデータ領域のサイズは固定長である、データベース管理方法。
  21. 　請求項２０に記載のデータベース管理方法であって、前記変換テーブルは、前記各データ識別子に対して、前記タプル識別子のデータ量が前記メタデータ領域の固定長サイズを超えたか否かを示すフラグ情報が格納されるフラグ領域を有する、データベース管理方法。
  22. 　請求項２０または２１に記載のデータベース管理方法であって、
    　前記データベースは、前記タプル識別子のデータ量が前記固定長サイズを超えるときに当該タプル識別子の全部または一部が格納されるオーバフロー領域を有し、
    　前記ステップ（ｂ）は、前記タプル識別子のデータ量が前記固定長サイズを超えるときに、当該タプル識別子の全部または一部を前記オーバフロー領域に格納するステップを含む、データベース管理方法。
  23. 　請求項２２に記載のデータベース管理方法であって、前記ステップ（ｂ）は、前記オーバフロー領域に前記タプル識別子が格納されるとき、当該タプル識別子の記憶領域の位置を示す位置データを前記メタデータ領域に格納するステップを含む、データベース管理方法。
  24. 　コンピュータによって読み取り可能な記録媒体であって、
    　複数の実体データを含むデータベースについてクエリを受信する処理と、
    　前記データベースに対して当該受信されたクエリに基づいて実行されるデータ処理と、
    を含むデータベース管理処理を前記コンピュータに実行させるコンピュータプログラムを格納し、
    　前記データベースは、
    　行方向に定義された少なくとも１つのタプルと列方向に定義された少なくとも１つの属性フィールドとで定まる領域に前記実体データそのものを一意に表す固定長のデータ識別子が格納されている識別子テーブルと、
    　前記複数の実体データそれぞれの記憶領域の位置を示す位置データと前記複数のデータ識別子との間の対応関係を表す変換テーブルと、
    を含み、
    　前記変換テーブルは、前記識別子テーブルにおいて前記各データ識別子が格納されている当該タプルを一意に表すタプル識別子が格納されるメタデータ領域を有することを特徴とする記憶媒体。
  25. 　請求項２４記載の記憶媒体であって、前記識別子テーブルに割り当てられた記憶領域と前記実体データに割り当てられた記憶領域とが互いに異なることを特徴とする記憶媒体。
  26. 　請求項２４または２５に記載の記憶媒体であって、前記メタデータ領域のサイズは固定長であることを特徴とする記憶媒体。
  27. 　請求項２６に記載の記憶媒体であって、前記変換テーブルは、前記各データ識別子に対して、前記タプル識別子のデータ量が前記メタデータ領域の固定長サイズを超えたか否かを示すフラグ情報が格納されるフラグ領域を有することを特徴とする記憶媒体。
  28. 　請求項２６または２７に記載の記憶媒体であって、
    　前記データベースは、前記タプル識別子のデータ量が前記固定長サイズを超えるときに当該タプル識別子の全部または一部が格納されるオーバフロー領域を有し、
    　前記データ処理は、前記タプル識別子のデータ量が前記固定長サイズを超えるときに、当該タプル識別子の全部または一部を前記オーバフロー領域に格納する処理を含むことを特徴とする記憶媒体。
  29. 　請求項２８に記載の記憶媒体であって、前記データ処理は、前記オーバフロー領域に前記タプル識別子が格納されるとき、当該タプル識別子の記憶領域の位置を示す位置データを前記メタデータ領域に格納する処理を含むことを特徴とする記憶媒体。
PCT/JP2010/000326 2009-01-26 2010-01-21 データベースシステム、データベース管理方法、データベース構造および記憶媒体 WO2010084754A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/144,828 US20110289112A1 (en) 2009-01-26 2010-01-21 Database system, database management method, database structure, and storage medium
JP2010547440A JPWO2010084754A1 (ja) 2009-01-26 2010-01-21 データベースシステム、データベース管理方法、及びデータベース構造

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2009-014142 2009-01-26
JP2009014142 2009-01-26

Publications (1)

Publication Number Publication Date
WO2010084754A1 true WO2010084754A1 (ja) 2010-07-29

Family

ID=42355810

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/000326 WO2010084754A1 (ja) 2009-01-26 2010-01-21 データベースシステム、データベース管理方法、データベース構造および記憶媒体

Country Status (3)

Country Link
US (1) US20110289112A1 (ja)
JP (1) JPWO2010084754A1 (ja)
WO (1) WO2010084754A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013025793A (ja) * 2011-07-14 2013-02-04 Lsi Corp フラッシュメディアコントローラの内部のメタデータハンドリング

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5392254B2 (ja) * 2008-05-30 2014-01-22 日本電気株式会社 データベースシステム、データベース管理方法、データベース構造およびコンピュータプログラム
US20120011143A1 (en) * 2010-07-09 2012-01-12 David Nash Publish and Subscribe Data Delivery System and Method Using Keys
US9304898B2 (en) * 2011-08-30 2016-04-05 Empire Technology Development Llc Hardware-based array compression
EP2843567B1 (en) * 2013-08-30 2017-05-10 Pilab S.A. Computer-implemented method for improving query execution in relational databases normalized at level 4 and above
US9465840B2 (en) * 2014-03-14 2016-10-11 International Business Machines Corporation Dynamically indentifying and preventing skewed partitions in a shared-nothing database
US10140348B2 (en) * 2015-04-25 2018-11-27 Phillip Hiroshige System for automatically tracking data through a plurality of data sources and plurality of conversions
WO2021210056A1 (ja) 2020-04-14 2021-10-21 日本電信電話株式会社 トラフィックモニタリング装置、方法及びプログラム
CN117076474B (zh) * 2023-10-16 2024-03-12 之江实验室 离线多模态文献数据的更新方法、装置、设备和介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004326772A (ja) * 2003-04-22 2004-11-18 Hewlett-Packard Development Co Lp ハッシュテーブルを使用するメモリ管理システム
JP2008533570A (ja) * 2005-03-11 2008-08-21 ロックソフト リミテッド 低冗長記憶システムで索引を行う方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5727197A (en) * 1995-11-01 1998-03-10 Filetek, Inc. Method and apparatus for segmenting a database
US8122040B2 (en) * 2007-08-29 2012-02-21 Richard Banister Method of integrating remote databases by automated client scoping of update requests over a communications network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004326772A (ja) * 2003-04-22 2004-11-18 Hewlett-Packard Development Co Lp ハッシュテーブルを使用するメモリ管理システム
JP2008533570A (ja) * 2005-03-11 2008-08-21 ロックソフト リミテッド 低冗長記憶システムで索引を行う方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013025793A (ja) * 2011-07-14 2013-02-04 Lsi Corp フラッシュメディアコントローラの内部のメタデータハンドリング

Also Published As

Publication number Publication date
JPWO2010084754A1 (ja) 2012-07-19
US20110289112A1 (en) 2011-11-24

Similar Documents

Publication Publication Date Title
WO2010084754A1 (ja) データベースシステム、データベース管理方法、データベース構造および記憶媒体
JP5922716B2 (ja) 個別にアクセス可能なデータユニットの記憶の取り扱い方法
US8620880B2 (en) Database system, method of managing database, and computer-readable storage medium
EP2729884B1 (en) Managing storage of data for range-based searching
US9916313B2 (en) Mapping of extensible datasets to relational database schemas
US20160253382A1 (en) System and method for improving a query response rate by managing a column-based store in a row-based database
US9104711B2 (en) Database system, method of managing database, and computer-readable storage medium
JP7274293B2 (ja) 情報処理装置、情報処理方法及びプログラム
AU2015258326B2 (en) Managing storage of individually accessible data units
Dean xqerl_db: Database Layer in xqerl
Pollack et al. Index Storage Fundamentals

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10733362

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13144828

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2010547440

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10733362

Country of ref document: EP

Kind code of ref document: A1