WO2009144941A1 - データベースシステム、データベース管理方法、データベース構造およびコンピュータプログラム - Google Patents

データベースシステム、データベース管理方法、データベース構造およびコンピュータプログラム Download PDF

Info

Publication number
WO2009144941A1
WO2009144941A1 PCT/JP2009/002359 JP2009002359W WO2009144941A1 WO 2009144941 A1 WO2009144941 A1 WO 2009144941A1 JP 2009002359 W JP2009002359 W JP 2009002359W WO 2009144941 A1 WO2009144941 A1 WO 2009144941A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
entity data
identifier
database
storage area
Prior art date
Application number
PCT/JP2009/002359
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 JP2010514373A priority Critical patent/JP5392253B2/ja
Priority to US12/995,164 priority patent/US8620880B2/en
Publication of WO2009144941A1 publication Critical patent/WO2009144941A1/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/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • 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/21—Design, administration or maintenance of databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • G06F16/9017—Indexing; Data structures therefor; Storage structures using directory or table look-up

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 Patent Document of International Publication No. 00/10103
  • 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 storing data.
  • Patent Document 2 and Patent Document 3 require that the item value numbers in the value management table be arranged in a predetermined order. For this reason, when a new item value number is inserted into the value management table during data update (for example, record update, insertion or deletion), it is necessary to rearrange other existing item value numbers. Furthermore, 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 computer program that enable efficient and high-speed execution of data update to a database.
  • a storage unit that stores a database including an entity data group including a plurality of entity data and a plurality of identifier tables having only a plurality of fixed-length data, the query is received, and the received query is included in the received query.
  • a database system including a data processing unit that executes data processing based on the database.
  • each identifier table includes at least one tuple defined in a row direction and a plurality of data identifiers defined in a column direction and uniquely representing the plurality of entity data themselves, as the fixed-length data.
  • the database includes a link table for associating a tuple between the identifier tables in addition to the plurality of identifier tables.
  • the data processing unit executes the data processing using the link table and the identifier table.
  • receiving a query for a database including an entity data group composed of a plurality of entity data and a plurality of identifier tables having only a plurality of fixed-length data; Performing a data processing based on the query.
  • Each identifier table includes at least one tuple defined in a row direction and a plurality of data identifiers defined in a column direction and uniquely representing the plurality of entity data themselves as the fixed-length data.
  • the database includes a link table that associates tuples between the identifier tables in addition to the plurality of identifier tables. The data processing is executed by using the link table and the identifier table.
  • a database structure including an entity data group composed of a plurality of entity data, a plurality of identifier tables having only a plurality of fixed-length data, and a link table for associating the identifier tables.
  • each identifier table includes at least one tuple defined in a row direction and a plurality of data identifiers defined in a column direction and uniquely representing the plurality of entity data themselves, as the fixed-length data.
  • Including at least one attribute field, and the link table associates tuples between the identifier tables.
  • the computer program which makes a computer perform a database management process includes a process of receiving a query for a database including an entity data group including a plurality of entity data and a plurality of identifier tables having only a plurality of fixed-length data;
  • Each of the identifier tables includes at least one tuple defined in a row direction, and each of the plurality of entity data itself defined in a column direction.
  • At least one attribute field including a plurality of data identifiers that uniquely represent the fixed-length data
  • the database includes a link table that associates tuples between the identifier tables in addition to the plurality of identifier tables, Data processing includes the link table and the identifier table. It is performed by there.
  • the database system includes a database including an entity data group and an identifier table having a fixed-length data identifier that uniquely represents a plurality of entity data itself in the entity data group. . Therefore, for example, when specific entity data in the entity data group is updated in response to a query, update processing for the database can be executed simply by updating the data identifier corresponding to the updated entity data.
  • update processing for the database can be executed simply by adding only the data identifier corresponding to the added entity data to the identifier table.
  • the database update process can be executed by deleting only the data identifier corresponding to the deleted entity data from the identifier table.
  • the identifier table is updated within the minimum necessary range as the entity data is updated, added or deleted, so that the database can be updated efficiently and at high speed.
  • the database management method and the computer program according to the present invention execute the update process for the database, the database can be updated efficiently and at high speed.
  • the database structure according to the present invention can be applied to a database incorporated in the database system.
  • the database structure can be applied to the database management method or the database used by the computer.
  • Updates to the database can be executed efficiently and at high speed.
  • 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) ) 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) ) 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) ) 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,
  • 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 (step S14; YES), 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 has a function of periodically setting 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 has a structure including an entity data group composed of a plurality of entity data and at least one identifier table having only a plurality of fixed-length data.
  • This identifier table has a plurality of data identifiers that substantially uniquely represent a plurality of entity data themselves as the fixed-length data.
  • the identifier table has at least one tuple defined in the row direction and at least one attribute field defined in the column direction and including a data identifier.
  • the transaction execution unit 23 When the transaction execution unit 23 selects specific entity data from the entity data group in response to a query request, the transaction execution unit 23 retrieves a fixed-length data identifier in the identifier table without retrieving the entity data group. The entity data can be selected based on the search result. The transaction execution unit 23 can execute a transaction including processing such as search and update for the database 41 using the selection result.
  • the defrag processing unit 31 reads these data identifiers from the storage device 40, and is assigned to the identifier table. Has a function of writing to a typical storage area.
  • FIG. 3 is a schematic diagram illustrating an example of a database structure according to the first embodiment of the present invention.
  • the database structure includes a group of actual data stored in the storage area DA0 of the storage device 40 and an identifier table RT0 stored in a storage area different from the storage area DA0.
  • the identifier table RT0 has four tuples defined in the row direction and four attribute fields TID, Val1, Val2, and Val3 defined in the column direction.
  • the number of tuples in the identifier table RT0 is four.
  • 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 TID, Val1, Val2, Val3 is not limited to four.
  • names (attribute names) of the attribute fields Val1, Val2, Val3 for example, “customer name”, “affiliation company name”, and “gender” can be set.
  • Unique tuple identifiers R1, R2, R3, and R4 are assigned to the four tuples of the identifier table RT0, respectively.
  • the attribute field Val1 includes fixed-length data identifiers VR11, VR21, VR31, and VR41 in areas corresponding to the four tuples
  • the attribute field Val2 includes fixed-length data identifiers VR12 and VR12 in areas corresponding to the four tuples.
  • the attribute field Val3 includes fixed-length data identifiers VR13, VR23, VR33, and VR43 in areas corresponding to the four tuples.
  • These 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 can access variable-length entity data corresponding to any of these 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 data identifiers VR11, VR12, and VR13 are set to Taro ”,“ Company N ”,“ Male ”entity data D11, D12, D13 are identifiers that uniquely represent the data identifiers VR21, VR22, VR23 are“ Sato Hanako ”,“ Company F ”,“ Women ”, respectively.
  • the entity data D21, D22, and D23 are uniquely represented as identifiers, and the data identifiers VR31, VR32, and VR33 are respectively represented by “Itoichi”, “S company”, and “unknown” entity data D31, D32, and D33. It can be an identifier to represent.
  • the values of such data identifiers VR11 to VR43 can be calculated using a one-way hash function. Since the hash function outputs a fixed-length bit string in response to the input of the actual data, the output value (hash value) of this hash function may be used as the values of the data identifiers VR11 to VR43.
  • the transaction execution unit 23 converts the search character string into a hash value, searches the identifier table RT0 for a data identifier having a value that matches the hash value, and selects entity data corresponding to the found data identifier. it can. At this time, the transaction execution unit 23 searches the identifier table RT0 including only the fixed-length data group, so that the character string can be searched at high speed. In particular, it is possible to execute a search in units of lines at high speed.
  • the data identifiers VR11 to VR41 are preferably recorded in a continuous area of the storage area. This speeds up access to the data identifiers VR11 to VR43 and increases the cache hit rate, thereby improving the search speed.
  • the data identifiers VR11 to VR43 may be distributed and stored in discontinuous storage areas.
  • the group of data identifiers VR11 to VR13 and the group of data identifiers VR21 to VR23 are stored in storage areas separated from each other.
  • the defragmenter 31 reads the data identifiers VR11 to VR43 from the storage area RA0 at a predetermined timing, and writes the read data identifiers VR11 to VR43 in the continuous area, thereby reducing the search speed. Can be prevented.
  • FIG. 5A schematically shows an example of the data structure stored in the storage area DA0.
  • This data structure has a header area at the beginning and an allocation management table at the end.
  • An area for storing the entity data group is provided between the header area and the allocation management table.
  • the header area includes a conversion table representing the correspondence between the position data indicating the storage area of each entity data and the data identifier. More specifically, as shown in FIG. 5B, the conversion table includes a plurality of data identifiers VR11 to VR43 and position data A11 to A43 indicating the storage areas of the plurality of entity data D11 to D43. It defines the correspondence between the two.
  • the position data A11 to A43 may be any address specifying the absolute position of the storage area of the corresponding entity data D11 to D43, or an offset specifying the relative position of the storage area.
  • the transaction execution unit 23 can access the entity data D11 to D43 by searching the identifier table RT0 and referring to the header area of FIG. In this way, by logically connecting the entity data group and the identifier table RT0 via the header area, it is possible to efficiently and rapidly update the database 41 as described later.
  • the entity data having a value can be stored in the storage area DA0 without overlapping. In other words, since the entity data group constituting the database 41 can be compressed and stored in the storage area DA0, the storage area DA0 can be used efficiently.
  • FIG. 6A is a diagram schematically showing another example of the data structure stored in the storage area DA0.
  • this data structure there is no header area including the above-described conversion table.
  • the entity data D13 is added with a search data identifier VR13 having the same value as the corresponding data identifier VR13 and a value DL13 indicating the bit length of the entity data D13. .
  • the transaction execution unit 23 can access the entity data D11 to D43 by searching the identifier table RT0 and further searching the search data identifiers VR11 to VR43 in FIG.
  • the update process for the database 41 can be executed efficiently and at high speed. That is, the database 41 according to the first embodiment includes a plurality of entity data D11 to D43 and a plurality of data identifiers VR11 to VR43 that substantially uniquely represent the entity data D11 to D43, respectively. For example, when replacing specific entity data D41 in the database 41 with new entity data in response to a query, entity data having the same value as this new entity data already exists in the storage area D0. Then, the update process for the database 41 can be executed only by replacing the data identifier VR41 in the identifier table RT0 with a new data identifier without actually rewriting the entity data D41 in the storage area D0.
  • the update process for the database 41 can be executed simply by adding the data identifier to be added to the identifier table RT0. Furthermore, when attempting to delete the entity data D41 from the entity data group in response to the query, the database 41 is not deleted immediately from the storage area D0, but only the data identifier VR41 is deleted from the identifier table RT0. Update processing for can be executed.
  • the storage area assigned to the identifier table RT0 and the storage area DA0 assigned to the entity data group are separate areas. In other words, the identifier table RT0 and the entity data group are completely separated. For this reason, it is easy to disperse and arrange the identifier table RT0 and the entity data group.
  • the identifier 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 defragmenter 31 rewrites the data identifiers VR11 to VR43 to continuous storage areas. Therefore, it is possible to prevent a decrease in access speed to the database 41.
  • FIG. 7 is a schematic diagram showing an example of a database structure according to the second embodiment of the present invention.
  • the database structure includes a group of actual data stored in the storage area DA1 of the storage device 40, a link table LT1 stored in a storage area different from the storage area DA1, It has second column tables (identifier tables) CT11 and CT12.
  • the reference table RT0 shown in FIG. 3 has a plurality of attribute fields (columns), and each column includes a data identifier.
  • Each of the column tables CT11 and CT12 of the present embodiment can be said to have a data structure corresponding to each column of the reference table RT0 in FIG.
  • the data structure of the column table CT11 and the data structure of the column table CT12 may be stored in a storage area where addresses are not continuous, or may be stored in a storage area where addresses are continuous.
  • the first column table CT11 has a plurality of tuples defined in the row direction and one attribute field Val defined in the column direction.
  • the attribute field Val is in each of the areas corresponding to the four tuples. It includes fixed length data identifiers VR12, VR12, VR11, VR11.
  • the second column table CT12 has a plurality of tuples defined in the row direction and one attribute field Val defined in the column direction. This attribute field Val is an area corresponding to four tuples. Includes fixed-length data identifiers VR23, VR24, VR22, and VR21, respectively.
  • the data identifiers VR12 and VR11 are identifiers uniquely representing the actual data D12 and D11 such as “Taro Yamada” and “Hanako Sato”, and the data identifiers VR21 to VR24 are “male”, “female”, and the like.
  • the entity data D21 to D24 are uniquely identified.
  • the data identifiers VR11 to VR24 have values that substantially uniquely represent the actual data D11 to D24 of the storage area DA1. Therefore, the transaction execution unit 23 can search the data identifiers VR11 to VR24, and access the variable-length entity data using the search result.
  • the storage area DA1 only needs to have a conversion table similar to the conversion table shown in FIGS. 5A and 5B, or the search data identifier shown in FIGS. 6A and 6B. May have the same search data identifier.
  • the data identifier is preferably recorded in a continuous area. This speeds up access to the data identifier and increases the cache hit rate, thereby improving the search speed. Even when the update to the database 41 is frequently performed, the defragmenter 31 reads a group of data identifiers from the storage area at a predetermined timing and writes the read data identifiers to the continuous area, thereby increasing the search speed. Can be prevented.
  • the link table LT1 has a structure that associates tuples between the first column table CT11 and the second column table CT12. That is, the link table LT1 has a plurality of tuples defined in the row direction and two attribute fields TID and OST defined in the column direction, and one attribute field TID uniquely represents the tuple.
  • the tuple identifiers R1, R2, R3, and R4 are included, and the other attribute field OST includes offsets Vo1, Vo2, Vo3, and Vo4 that specify the relative positions of the tuple storage areas of the column tables CT11 and CT12. For example, by adding the offset Vo1 to a predetermined reference address A0, the effective address Vo1 + A0 that specifies the absolute position of the storage area of the data identifier VR12 can be obtained.
  • the values of the data identifiers VR11 to VR24 included in each of the first and second column tables CT11 and CT12 may be calculated using a one-way hash function.
  • the transaction execution unit 23 converts the search character string into a hash value, searches the column tables CT11 and CT12 for data identifiers having values that match the hash values, and selects entity data corresponding to the found data identifiers. be able to. At this time, the transaction execution unit 23 searches the column tables CT11 and CT12 including only the fixed-length data group, so that the character string can be searched at high speed.
  • the database according to the second embodiment can be regarded as two-column tabular data decomposed into a first column table CT11, a second column table CT12, and an entity data group. Therefore, it is possible to execute search processing in units of columns at high speed.
  • the number of attribute fields Val for each of the column tables CT11 and CT12 is one.
  • the number of attribute fields for each of the column tables CT11 and CT12 is, for example, 2 You may set more than.
  • the number of column tables CT11 and CT12 is not limited to two, and may be three or more.
  • the update process for the database 41 can be executed efficiently and at high speed.
  • the database according to the second embodiment includes a plurality of entity data and a plurality of data identifiers VR11 to VR24 that substantially uniquely represent the entity data. For this reason, as in the case of the first embodiment, database processing for an update query such as update, addition, or deletion of entity data can be efficiently executed, and high real-time performance can be ensured. Therefore, even when updates to the database 41 are frequently performed, it is possible to execute such updates efficiently and at high speed.
  • the logical connection form between tuples between the column tables CT11 and CT12 can be determined flexibly. For example, as shown in FIG. 7, using the offset Vo3 corresponding to the tuple identifier R3, the tuple recorded after the effective address A0 + Vo3 of the column table CT11 and the effective address A1 + Vo3 of the column table CT12 are recorded. Tuples can be logically connected. At the same time, using the offset Vo4 corresponding to the tuple identifier R4, the tuple recorded after the effective address A0 + Vo4 of the column table CT11 and the tuple recorded after the effective address A1 + Vo4 of the column table CT12 are logically connected. can do.
  • the column tables CT11 and CT12 are logically connected by only one attribute field OST of the link table LT1, the data capacity of the link table LT1 can be very small.
  • FIG. 8 is a schematic diagram illustrating an example of a database structure according to the third embodiment of the present invention.
  • this database structure includes a group of actual data stored in the storage area DA1 of the storage device 40, a link table LT2, a first and a first table stored in a storage area different from the storage area DA1.
  • the database structure according to the third embodiment has the same configuration as the database structure according to the second embodiment except for the link table LT2.
  • the link table LT2 has a structure that associates tuples between the first column table CT11 and the second column table CT12. That is, the link table LT2 has a plurality of tuples defined in the row direction and first to third attribute fields TID, PT1, PT2 defined in the column direction.
  • the first attribute field TID includes tuple identifiers R1, R2, R3, R4 that uniquely represent tuples.
  • the second attribute field PT1 includes pointers Vp11, Vp12, Vp13, and Vp14 that point to addresses assigned to the tuple storage areas of the column table CT11.
  • the third attribute field PT2 includes pointers Vp21, Vp22, Vp23, and Vp24 that point to addresses assigned to the tuple storage areas of the column table CT12.
  • the transaction execution unit 23 can search the data identifiers VR11 to VR24 in the first and second column tables CT11 and CT12 via the link table LT2, and can access the entity data using the search results.
  • the database of the third embodiment can be regarded as two-column tabular data divided into a first column table CT11, a second column table CT12, and a substantial data group. Therefore, it is possible to execute search processing in units of columns at high speed.
  • the number of column tables CT11 and CT12 is not limited to two, and may be three or more. Even in this case, the link table LT2 has attribute fields respectively corresponding to a plurality of column tables.
  • the effects of the database system 10 by using the database structure according to the third embodiment are as follows. As in the case of the second embodiment, first, the update process for the database 41 can be executed efficiently and at high speed, and secondly, the effect of high database dispersibility is obtained.
  • the logical connection form between tuples between the column tables CT11 and CT12 can be determined flexibly. That is, since the link table LT2 has an attribute field including a pointer for each column table, the database structure according to the third embodiment is more columnar than the database structure according to the second embodiment. It is possible to determine the connection form between tuples between them more flexibly.
  • the data identifiers VR23, VR24, VR22, VR21 in the column table CT12 in the link table LT2 can be changed by simply changing any one of the pointers Vp21, Vp22, Vp23, Vp24 in the attribute field PT2 of the link table LT2. The logical position of, ... can be changed. At this time, the other column table CT11 is not affected.
  • the column table CT11 has the same data identifiers VR12 and VR12, but by changing the pointer of the attribute field PT1 of the link table LT2 (for example, the pointer Vp12 is changed). By changing to Vp11), the duplication can be eliminated and the data capacity can be compressed.
  • the transaction execution unit 23 performs the first column table CT11 according to the query that specifies the search condition. And the search processing for the second column table CT12 can be performed in parallel. Therefore, the search speed can be improved.
  • FIG. 9 is a schematic diagram showing an example of a database structure according to the fourth embodiment of the present invention.
  • the database structure includes an entity data group stored in the storage area DA2 of the storage device 40, a link table LT3 stored in a storage area different from the storage area DA2, the first and first 2 column tables (identifier tables) CT31 and CT32.
  • the reference table RT0 shown in FIG. 3 has a plurality of attribute fields (columns), and each column includes a data identifier.
  • Each of the column tables CT31 and CT32 of this embodiment can be said to have a data structure corresponding to each column of the reference table RT0 of FIG.
  • the data structure of the column table CT31 and the data structure of the column table CT32 may each be configured in a storage area where addresses are not continuous, or may be configured in a storage area where addresses are continuous.
  • the first column table CT31 has four tuples defined in the row direction and two attribute fields Col1 and Val defined in the column direction.
  • One attribute field Col1 corresponds to the four tuples.
  • Each region includes fixed-length tuple identifiers CRV1, CRV2, CRV3, and CRV4, and the other attribute field Val includes fixed-length data identifiers VR12, VR12, VR11, and VR11, respectively, in regions corresponding to the four tuples.
  • Each of the tuple identifiers CRV1, CRV2, CRV3, and CRV4 of the first column table CT31 has a value that uniquely represents the tuple of the first column table CT31.
  • the second column table CT32 has four tuples defined in the row direction and two attribute fields Col2 and Val defined in the column direction.
  • One attribute field Col2 corresponds to the four tuples.
  • Each region includes fixed-length tuple identifiers CRV1, CRV2, CRV3, and CRV4, and the other attribute field Val includes fixed-length data identifiers VR23, VR24, VR21, and VR22, respectively, in regions corresponding to the four tuples.
  • Each of the tuple identifiers CRV1, CRV2, CRV3, and CRV4 of the second column table CT32 has a value that uniquely represents the tuple of the second column table CT32.
  • the data identifiers VR11 to VR24 have values that substantially uniquely represent the actual data D11 to D24 of the storage area DA2. Therefore, the transaction execution unit 23 can search the data identifiers VR11 to VR24, and access the variable-length entity data using the search result.
  • the storage area DA2 may have a conversion table similar to the conversion table shown in FIGS. 5A and 5B, or the search data identifier shown in FIGS. 6A and 6B. May have the same search data identifier.
  • the data identifier is preferably recorded in a continuous area. This speeds up access to the data identifier and increases the cache hit rate, thereby improving the search speed. Even when the update to the database 41 is frequently performed, the defragmenter 31 reads a group of data identifiers from the storage area at a predetermined timing and writes the read data identifiers to the continuous area, thereby increasing the search speed. Can be prevented.
  • the link table LT3 has a structure that associates tuples between the first column table CT31 and the second column table CT32. That is, the link table LT3 has four tuples defined in the row direction and two attribute fields TID and ColRef defined in the column direction. One attribute field TID uniquely represents the tuple.
  • the tuple identifiers R1, R2, R3, and R4 are included, and the other attribute field ColRef includes external tuple identifiers CRV1, CRV2, CRV3, and CRV4 that substantially uniquely represent the tuples (external tuples) of the column tables CT31 and CT32.
  • the external tuple identifiers CRV1, CRV2, CRV3, and CRV4 have the same values as the tuple identifiers CRV1, CRV2, CRV3, and CRV4 of the first column table CT31 and the second column table CT32, respectively, but are not limited thereto. is not.
  • These tuple identifiers may have values corresponding to the external tuple identifiers CRV1, CRV2, CRV3, and CRV4, respectively.
  • the values of the data identifiers VR11 to VR24 included in each of the first and second column tables CT31 and CT32 may be calculated using a one-way hash function.
  • the transaction execution unit 23 converts the search character string into a hash value, searches the column tables CT31 and CT32 for a data identifier having a value that matches the hash value, and selects entity data corresponding to the found data identifier. be able to. At this time, the transaction execution unit 23 searches the column tables CT31 and CT32 including only the fixed-length data group, so that the character string can be searched at high speed.
  • the database of the fourth embodiment can be regarded as two-column tabular data decomposed into a first column table CT31, a second column table CT32, and an entity data group. Therefore, it is possible to execute search processing in units of columns at high speed.
  • the number of attribute fields in each of the column tables CT31 and CT32 is two. However, the number of attribute fields is not limited to this. For example, the number of attribute fields in each of the column tables CT31 and CT32 may be set to three or more. . The number of column tables CT31 and CT32 is not limited to two, and may be three or more.
  • update processing for the database 41 can be executed efficiently and at high speed.
  • the database is highly distributed, and third, the column table. The logical connection form between tuples between CT31 and CT32 can be determined flexibly.
  • FIG. 10 is a schematic diagram showing an example of a database structure according to the fifth 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 can have a data structure stored in a storage area different from the storage area DA3.
  • each data structure of the intermediate identifier tables IT41, IT42, IT43 may be configured in a storage area where addresses are not continuous, or may be configured in a storage area where addresses are continuous.
  • the intermediate identifier tables IT41, IT42, IT43 may have a data structure stored in the storage area DA3.
  • the storage area DA3 has a header area similar to the header area of FIG. 5, and the data structures of the intermediate identifier tables IT41, IT42, and IT43 need only be stored in the header area together with the conversion table.
  • the first intermediate identifier table IT41 has two tuples defined in the row direction and two attribute fields Col1 and Val defined in the column direction.
  • One attribute field Col1 includes fixed-length tuple identifiers CRV11 and CRV12 in areas corresponding to two tuples.
  • the other attribute field Val includes fixed-length data identifiers VR11 and VR12 in areas corresponding to the two tuples.
  • the second intermediate identifier table IT42 has four tuples defined in the row direction and two attribute fields Col2 and Val defined in the column direction.
  • One attribute field Col2 includes fixed-length tuple identifiers CRV21, CRV22, CRV23, and CRV24 in areas corresponding to the four tuples.
  • the other attribute field Val of the second intermediate identifier table IT42 includes fixed-length data identifiers VR21, VR22, VR23, and VR24 in areas corresponding to the four tuples.
  • the third intermediate identifier table IT43 has three tuples defined in the row direction and two attribute fields Col3 and Val defined in the column direction.
  • One attribute field Col3 includes fixed-length tuple identifiers CRV31, CRV32, and CRV33 in areas corresponding to the three tuples.
  • the other attribute field Val of the third intermediate identifier table IT43 includes data identifiers VR31, VR32, VR33 having fixed lengths in the areas corresponding to the three tuples, respectively.
  • the first to third intermediate identifier tables IT41, IT42, and IT43 have data identifiers VR11 to VR33 that substantially uniquely represent the actual data D11 to D33 of the storage area DA3.
  • the reference table RT1 has reference identifiers CRV11 to CRV33 that substantially uniquely represent the data identifiers VR11 to VR33 in the first to third intermediate identifier tables IT41 to IT43, respectively.
  • the reference identifiers CRV11 to CRV33 have the same values as the tuple identifiers CRV11 to CRV33 in the first to third intermediate identifier tables IT41 to IT43, respectively, and thereby the data identifiers VR11 to VR33.
  • the values of the reference identifiers CRV11 to CRV33 can be values of hash functions when the data identifiers VR11 to VR33 are input, respectively.
  • the reference table RT1 has four tuples defined in the row direction, and first to fourth attribute fields TID, Col1Ref, Col2Ref, and Col3Ref defined in the column direction. Yes.
  • the first attribute field TID includes tuple identifiers R1, R2, R3, R4 that uniquely represent tuples.
  • the second attribute field Col1Ref includes a set of reference identifiers CRV12, CRV12, CRV11, and CRV11 that substantially uniquely represent the data identifiers VR11 and VR12 of the first intermediate identifier table IT41
  • the third attribute field Col2Ref is
  • the second intermediate identifier table IT42 includes a set of reference identifiers CRV21, CRV22, CRV23, and CRV24 that uniquely represent the data identifiers VR21, VR22, VR23, and VR24 of the second intermediate identifier table IT42
  • the fourth attribute field Col3Ref includes a third intermediate field It includes a set of reference identifiers CRV31, CRV32, CRV33 that substantially uniquely represent the data identifiers VR31, VR32, VR33 of the identifier table IT43.
  • the data identifiers CRV12, CRV23, and CRV32 in the tuple (record) corresponding to the tuple identifier R1 are identifiers that uniquely represent the data identifiers VR12, VR23, and V32, and these data identifiers VR12, VR23, and V32 are:
  • the identifiers uniquely represent the entity data D12, D23, and D32 of “Shinagawa”, “N company”, and “20's”, respectively.
  • the data identifiers CRV12, CRV24, and CRV33 in the tuple corresponding to the tuple identifier R2 are identifiers that uniquely represent the data identifiers VR12, VR24, and VR33, and these data identifiers VR12, VR24, and VR33 are respectively “ It is an identifier that uniquely represents entity data D12, D24, and D33 of “Tamachi”, “Company A”, and “30's”.
  • the data identifiers CRV11, CRV21, and CRV33 in the tuple corresponding to the tuple identifier R3 are identifiers that uniquely represent the data identifiers VR11, VR21, and VR33, and these data identifiers VR11, VR21, and VR33 are respectively “Tamachi”. ”,“ Company A ”, and“ 30's ”entity data D11, D21, and D33 are identifiers that uniquely represent the data.
  • the data identifiers CRV11, CRV22, and CRV31 in the tuple corresponding to the tuple identifier R4 are identifiers that uniquely represent the data identifiers VR11, VR22, and V31, and these data identifiers VR11, VR22, and V31 are respectively “Tamachi”. ”,“ Company S ”, and“ 40's ”entity data D11, D22, D31 are identifiers that uniquely represent the data.
  • the values of the data identifiers VR11 to VR33 included in each of the first to third intermediate identifier tables IT41, IT42, and IT43 are calculated using a one-way hash function. do it.
  • the values of the reference identifiers CRV11 to CRV33 can be calculated using a hash function. For example, the output value of the hash function when the values of the data identifiers VR11 to VR33 are input may be used as the values of the reference identifiers CRV11 to CRV33.
  • the transaction execution unit 23 converts the search character string into a hash value, searches the reference table RT1 for a reference identifier having a value that matches the hash value, and accesses entity data corresponding to the found reference identifier. it can. At this time, the transaction execution unit 23 searches the reference table RT1 including only the fixed-length data group, so that the character string can be searched at high speed.
  • 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.
  • the storage area DA3 only needs to have a conversion table similar to the conversion table shown in FIGS. 5A and 5B, or the search data identifier shown in FIGS. 6A and 6B. May have the same search data identifier.
  • each of the first to third intermediate identifier tables IT41, IT42, IT43 excludes data identifiers having overlapping values, it has a data structure that eliminates redundancy. As a result, the storage area can be used efficiently.
  • the data identifier is preferably recorded in a continuous area. Also in the reference table RT1, it is desirable that the reference identifiers CRV11 to CRV33 are recorded in a continuous area. This speeds up access to the data identifier and the reference identifier and increases the cache hit rate, thereby improving the search speed.
  • the defragmenter 31 reads a group of data identifiers or a group of reference identifiers from the storage area at a predetermined timing, and continuously reads the read data identifiers or reference identifiers. By writing in the area, it is possible to prevent a decrease in search speed.
  • the defrag processing unit 31 sets the plurality of data identifiers in the attribute field Val in each of the first to third intermediate identifier tables IT41 to IT43 in ascending or descending order of the value of the reference identifier corresponding to the data identifier. Has the function of rearranging. Thereby, it becomes possible to perform a search process efficiently.
  • the update process for the database 41 can be executed efficiently and at high speed.
  • the database according to the fifth embodiment includes a plurality of entity data and a plurality of data identifiers VR11 to VR33 that substantially uniquely represent the entity data. For this reason, not only the intermediate identifier tables IT41 to IT43 but also the reference table RT1 are updated to the minimum necessary as the records are updated, added or deleted. Therefore, even when the database 41 is frequently updated, such an update is performed. It can be executed efficiently and at high speed.
  • the transaction execution unit 23 converts the record into a reference record including a reference identifier, and newly associates the reference record with the tuple identifier R5 in the reference table RT1. to add.
  • the transaction execution unit 23 determines whether or not the reference identifier (new reference identifier) in the newly added reference record exists in the existing reference records corresponding to the tuple identifiers R1 to R4. When it is determined that the new reference identifier exists in the existing reference record, the transaction execution unit 23 ends the update process for the database 41.
  • the transaction execution unit 23 adds the data identifier corresponding to the new reference identifier to any of the intermediate identifier tables IT41 to IT43, and the new reference.
  • the entity data corresponding to the identifier is added to the storage area DA3.
  • the reference table RT1 is updated, so that the update process for the database 41 can be completed in a short time.
  • the reference record to be newly added includes a new reference identifier CRV13 that does not exist in the reference table RT1
  • the tuple identifier CRV13 and the data identifier VR13 are added to the intermediate identifier table IT41.
  • the entity data D13 is added to the storage area DA3.
  • the reference record to be newly added includes only the new reference identifier CRV11 already existing in the reference table RT1, it is not necessary to update the intermediate identifier tables IT41 to IT43 and the entity data group.
  • the intermediate identifier tables IT41 to IT43 and the entity data group are completely separated. Therefore, as in the first embodiment, it is easy to disperse and arrange the intermediate identifier tables IT41 to IT43 and the entity data group. In addition, the intermediate identifier tables IT41 to IT43 and the reference table RT1 can be easily distributed.
  • FIG. 11 is a schematic diagram showing an example of a database structure according to the sixth embodiment of the present invention.
  • this database structure includes a group of actual data stored in the storage area DA4 of the storage device 40, a reference table RT1 stored in a storage area different from the storage area DA4, and the first to first items.
  • the storage area DA4 assigned to the actual data group is divided into a plurality of partition areas PA1, PA2, PA3.
  • These partition areas PA1, PA2 and PA3 are allocated as areas for storing entity data of different data types in the entity data group. For example, only integer type entity data is stored in the partition area PA1, only character string type entity data is stored in the partition area PA2, and only date type entity data is stored in the partition area PA3.
  • the number of partition areas PA1, PA2, and PA3 is three, but the present invention is not limited to this.
  • the storage area DA4 can be efficiently used by storing the entity data in the partition area corresponding to the data type of the entity data.
  • FIG. 12A is a schematic diagram showing an example of a database structure according to the seventh embodiment of the present invention.
  • this database structure includes a group of actual data stored in the storage area DA5 of the storage device 40, a reference table RT1 stored in a storage area different from the storage area DA5, and the first table. It has first to third intermediate identifier tables IT41, IT42, IT43.
  • the first to third intermediate identifier tables IT41, IT42, and IT43 substantially uniquely represent the entity data D11 to D33 in the storage area DA5.
  • Data identifiers VR11 to VR33 are included.
  • the entity data D11 to D33 are included in the combined data KD11 to KD33, respectively.
  • data identifiers having mutually overlapping values are excluded.
  • FIG. 12 (B) is a diagram schematically showing the structure of the combined data KD12.
  • the combined data KD12 includes entity data D12, first sub-entity data T12a, and second sub-entity data T12b.
  • entity data D12, the first sub entity data T12a, and the second sub entity data T12b are stored in a continuous storage area.
  • the first sub entity data T12a and the second sub entity data T12b have contents related to the entity data D12.
  • the first sub-entity data T12a can be text data indicating the contents of the binary data.
  • the entity data D12 is data representing the content of the character string type “11”
  • the first sub entity data T12a represents the content of the integer type “11”
  • the second sub entity data T12b is The contents of the floating point type “11.00” may be represented.
  • the entity data D12 is data representing the content of Japanese text
  • the first sub-entity data T12a may represent the content of English text
  • the second sub-entity data T12b may represent the content of Russian text. .
  • the transaction execution unit 23 When the transaction execution unit 23 searches the reference table RT1 and the intermediate identifier tables IT41 to IT43 and selects the entity data D12 in response to the query request, the transaction execution unit 23 reads the sub-entity data T12a and T12b together with the entity data D12. it can. Alternatively, sub-substance data T12a or T12b may be read instead of the substantive data D12.
  • the transaction execution unit 23 converts the entity data D12 read from the database 41 into the first sub-entity data T12a and the second sub-entity data in response to a query request. Since it is not necessary to convert to T12b, the response speed to the query can be improved.
  • FIG. 13 is a schematic diagram showing a part of the database structure according to the eighth embodiment of the present invention. As shown in FIG. 13, this database structure has a group of actual data stored in the storage area DA6 of the storage device 40, and a reference table RT1 (not shown) stored in a storage area different from the storage area DA6. And first to third intermediate identifier tables IT41, IT42, IT43 (not shown).
  • combined data MD11 to MD33 including entity data D11 to D33 corresponding to the data identifiers VR11 to VR33 of the intermediate identifier tables IT41, IT42, IT43 are stored in the partition area QA1 of the storage area DA6.
  • combined data MT11a to MT33a including sub-entity data T11a to T33a having contents related to the entity data D11 to D33, respectively, are stored.
  • combined data MT11b to MT33b including sub-entity data T11b to T33b having contents related to the entity data D11 to D33 are stored.
  • position data P31 indicating the position of the storage area of the sub entity data T31a having contents related to the entity data D31 is added. Furthermore, position data P31a indicating the position of the storage area of the sub-substance data T31b having contents related to the sub-data D31 is added to the sub-substance data T31a.
  • the database structure according to the present embodiment has a structure in which the entity data D31 and the sub entity data T31a and T31b are logically connected.
  • the position data P31 and P31a may be an address that specifies the absolute position of the storage area, an offset that specifies the relative position of the storage area, or a pointer that points to an address assigned to the storage area. The same applies to other entity data.
  • the transaction execution unit 23 When the transaction execution unit 23 searches the reference table RT1 and the intermediate identifier tables IT41 to IT43 and selects the entity data D31 in response to the query request, the transaction execution unit 23 reads the sub-entity data T31a and T31b together with the entity data D31. it can. Alternatively, sub-substance data T31a or T31b can be read instead of the substantive data D31.
  • the transaction execution unit 23 uses the first sub entity data T31a and the second sub entity data T31 read from the database 41 in response to a query request. Since it is not necessary to convert the data into the entity data T31b, the response speed to the query can be improved.
  • FIG. 15 is a schematic diagram showing an example of a database structure according to the ninth embodiment of the present invention.
  • this database structure includes an entity data group stored in the storage area DA7 of the storage device 40, a reference table RT1 stored in a storage area different from the storage area DA7, and the first to first data.
  • Entity data D11 to D33 are stored in the partition area RA1 of the storage area DA7.
  • sub-substance data T11a to T33a having contents related to the substantive data D11 to D33 are stored in the partition area RA2 of the storage area DA7.
  • the intermediate identifier table IT41a has an attribute field TR in addition to the attribute fields Col1 and Val of the intermediate identifier table IT41 (FIG. 10).
  • This attribute field TR includes sub-data identifiers VT11 and VT12 which correspond one-to-one with the data identifiers VR11 and VR12 in the attribute field Val and which substantially uniquely represent the sub-substance data T11a and T12a.
  • the intermediate identifier table IT42a has an attribute field TR in addition to the attribute fields Col2 and Val of the intermediate identifier table IT42 (FIG. 10).
  • the attribute field TR is a data identifier VR21 in the attribute field Val.
  • the intermediate identifier table IT43a has an attribute field TR in addition to the attribute fields Col3 and Val of the intermediate identifier table IT43 (FIG. 10).
  • the attribute field TR includes data identifiers VR31 to VR33 in the attribute field Val.
  • Sub-data identifiers VT31 to VT33 that correspond one-to-one and substantially uniquely represent sub-substance data T31a to T33a are included.
  • the values of the sub-data identifiers VT11 to VT33 may be calculated using a hash function that outputs a fixed-length bit string in response to the input of sub-substance data.
  • the transaction execution unit 23 searches the reference table RT1 and the intermediate identifier tables IT41a to IT43a in response to a query and selects, for example, the entity data D12 from the entity data group, the selected entity data D12 is selected.
  • the sub-substance data T12a having the contents related to can be read using the sub-data identifier VT12.
  • the sub entity data T12a can be read instead of the entity data D12.
  • the transaction execution unit 23 does not have to convert the entity data D12 read from the database 41 into the sub-entity data T12a in response to the query request.
  • the response speed to the query can be improved.
  • FIG. 16 is a schematic diagram illustrating an example of a database structure according to the tenth embodiment of the present invention.
  • this database structure includes an entity data group stored in the storage area DA8 of the storage device 40, a reference table RT1 stored in a storage area different from the storage area DA8, and the first to first items.
  • the storage area DA8 assigned to the actual data group is divided into a plurality of partition areas PAa, PAb, PAc, and PAd.
  • These partition areas PAa, PAb, PAc, and PAd are allocated as areas for storing entity data having different combinations of data types and data formats in the entity data group.
  • Examples of the data type include an integer type, a character string type, and a date type.
  • Examples of the data format include a Japanese format and an English format, but are not limited thereto.
  • FIG. 17 is a diagram (conversion table) showing the correspondence between the combination of data type and data format and the partition area.
  • the database structure of the present embodiment may include the conversion table of FIG. 17, or the conversion table of FIG. 17 may be stored in a storage area different from the storage area allocated to the database 41.
  • the conversion table of FIG. 17 only the actual data group having a combination of data format 1 and data type 1 is stored in the partition area PAa, and data format 2 and data type 1 are stored in the partition area PAb. Only the sub-substance data group having the combination is stored, only the sub-substance data group having the combination of data format 1 and data type 2 is stored in the partition area PAc, and the data format 2 and data type are stored in the partition area PAd. Only sub-substance data groups having a combination of 2 are stored.
  • the transaction execution unit 23 selects any one storage area from the partition areas PAa to PAd with reference to the conversion table in FIG. Sub-substance data can be read.
  • the transaction execution unit 23 does not need to convert the entity data read from the database 41 into the sub-entity data in response to the query request. Response speed can be improved.
  • the above embodiment is an exemplification 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, but may simply include a value for calling an API (Application Programming Interface) function for a database.
  • API Application Programming Interface
  • the structure of the storage area DA4, DA5, DA6, DA7 or DA8 according to the sixth to tenth embodiments is applied instead of the storage area DA0, DA1, DA2 or DA3 according to the first to fifth embodiments. May be.
  • the column tables CT11 and CT12 according to the second embodiment or the third embodiment may be stored in storage areas separated from each other, or may be stored in continuous storage areas. These column tables CT11 and CT12 may be incorporated in the header area of the storage area in which the entity data group is stored.
  • the column tables CT31 and CT32 according to the fourth embodiment may also be stored in storage areas that are separated from each other, may be stored in continuous storage areas, or may store entity data groups. It may be incorporated in the header area of the storage area.
  • the intermediate identifier tables IT41 to IT43 according to the respective embodiments of the fifth to seventh and tenth embodiments may be stored in storage areas separated from each other or stored in continuous storage areas. Alternatively, it may be incorporated in the header area of the storage area where the entity data group is stored. The same applies to the intermediate identifier tables IT41a to IT43a of the ninth embodiment.
  • the databases of the second, third, and fourth embodiments all have tabular data of N columns (N is an integer of 2 or more), one link table, N column tables, and an entity. It has a structure that can be decomposed into data groups. Therefore, it is possible to execute search processing in units of columns at high speed.
  • the database according to the first embodiment has a structure that can decompose tabular data of M rows and N columns (M is an integer of 2 or more) into an identifier table of M rows and N columns and a substance data group. The search processing in units of rows can be executed at a higher speed than the second, third, and fourth databases.
  • the tabular data is used in the second, third, or fourth embodiment in order to improve the search speed in column units. It is preferable to decompose the data into N column tables, link tables, and entity data groups. On the other hand, if the number of columns of the N-column table-format data is equal to or greater than a certain number, the table-format data is used as the identifier of the M-row N-column of the first embodiment in order to improve the search speed in units of rows. It is preferable to decompose the data into a table and an entity data group.

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 (71)

  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. 　請求項２８記載のデータベース管理方法であって、前記外部タプル識別子は固定長のビット列である、データベース管理方法。
  30. 　請求項２３から２９のうちのいずれか１項に記載のデータベース管理方法であって、
    　前記データベースは、前記複数の実体データそれぞれの記憶領域を示す位置データと前記複数のデータ識別子との間の対応関係を表す変換テーブルを含み、
    　前記データ処理は、前記変換テーブルを用いて前記実体データ群の中から実体データを選択し、この選択結果を用いることによって実行される、データベース管理方法。
  31. 　請求項２３から２９のうちのいずれか１項に記載のデータベース管理方法であって、
    　前記複数の実体データには、それぞれ、前記複数のデータ識別子と同じ値を持つ検索用データ識別子が付加されており、
    　前記データ処理は、前記検索用データ識別子を検索し、この検索結果に基づいて前記実体データを選択し、この選択結果を用いることによって実行される、データベース管理方法。
  32. 　請求項２３から３１のうちのいずれか１項に記載のデータベース管理方法であって、前記複数のデータ識別子が不連続な複数の記憶領域に分散して記憶されているとき、前記複数のデータ識別子を記憶部から読み出し、当該読み出されたデータ識別子を、前記識別子テーブルに割り当てられた連続的な記憶領域に書き込むステップを更に備えるデータベース管理方法。
  33. 　請求項２３から３２のうちのいずれか１項に記載のデータベース管理方法であって、
    　前記実体データ群に割り当てられた記憶領域は、複数のパーティション領域に分割され、
    　前記複数のパーティション領域は、それぞれ、前記実体データ群のうち互いに異なるデータ型の実体データを記憶する領域として割り当てられている、データベース管理方法。
  34. 　請求項２３から３２のうちのいずれか１項に記載のデータベース管理方法であって、
    　前記データベースは、前記複数の実体データにそれぞれ関連した内容を有する複数のサブ実体データを含み、
    　前記実体データと当該実体データに関連した内容を有するサブ実体データとが連続的な記憶領域に記憶されており、
    　前記データ処理は、前記識別子テーブルを検索して前記実体データ群の中から実体データを選択したとき、当該選択された実体データに関連した内容を有するサブ実体データを前記データベースから読み出すことによって実行される、データベース管理方法。
  35. 　請求項２３から３２のうちのいずれか１項に記載のデータベース管理方法であって、
    　前記データベースは、前記複数の実体データにそれぞれ関連した内容を有する複数のサブ実体データを含み、
    　前記各実体データには、当該各実体データに関連した内容を有する前記サブ実体データの記憶領域の位置を示す位置データが付加されており、
    　前記データ処理は、前記識別子テーブルを検索して前記実体データ群の中から実体データを選択したとき、当該選択された実体データに付加された位置データで指定されるサブ実体データを前記データベースから読み出すことによって実行される、データベース管理方法。
  36. 　請求項３５記載のデータベース管理方法であって、前記サブ実体データの記憶領域の位置を示す位置データは、前記サブ実体データの記憶領域の絶対的位置を指定するアドレスである、データベース管理方法。
  37. 　請求項３５記載のデータベース管理方法であって、前記サブ実体データの記憶領域の位置を示す位置データは、前記サブ実体データの記憶領域の相対的位置を指定するオフセットである、データベース管理方法。
  38. 　請求項２３から３２のうちのいずれか１項に記載のデータベース管理方法であって、
    　前記データベースは、前記複数の実体データにそれぞれ関連した内容を有する複数のサブ実体データを含み、
    　前記識別子テーブルは、前記データ識別子に一対一で対応しかつ前記サブ実体データの記憶領域に関連付けられたサブデータ識別子を更に含み、
    　前記データ処理は、前記識別子テーブルを検索して前記実体データ群の中から実体データを選択したとき、当該選択された実体データに関連した内容を有するサブ実体データを前記サブデータ識別子を用いて前記データベースから読み出すことによって実行される、データベース管理方法。
  39. 　請求項２３から３２のうちのいずれか１項に記載のデータベース管理方法であって、
    　前記データベースは、前記実体データ群に関連した内容を有する少なくとも１つのサブ実体データ群を含み、
    　前記データ処理は、当該受信されたクエリに基づいて、前記実体データ群に割り当てられた第１の記憶領域と前記サブ実体データ群に割り当てられた第２の記憶領域とのいずれか一方を選択することによって実行される、データベース管理方法。
  40. 　複数の実体データからなる実体データ群と、
    　複数の固定長データのみを有する複数の識別子テーブルと、
    　前記識別子テーブル間を関連付けるリンクテーブルと、
    を含み、
    　前記各識別子テーブルは、行方向に定義された少なくとも１つのタプルと、列方向に定義され、かつ前記複数の実体データそのものをそれぞれ一意に表す複数のデータ識別子を前記固定長データとして含む少なくとも１つの属性フィールドとを有しており、
    　前記リンクテーブルは、前記識別子テーブル間のタプルを関連付ける、データベース構造。
  41. 　請求項４０記載のデータベース構造であって、前記識別子テーブルに割り当てられた記憶領域と前記実体データ群に割り当てられた記憶領域とが互いに異なる、データベース構造。
  42. 　請求項４０または４１記載のデータベース構造であって、前記データ識別子の値は、前記実体データの入力に対して固定長のビット列を出力するハッシュ関数の出力値である、データベース構造。
  43. 　請求項４０から４２のうちのいずれか１項に記載のデータベース構造であって、
    　前記リンクテーブルは、行方向に定義された少なくとも１つのタプルと、列方向に定義された少なくとも１つの属性フィールドとを有しており、
    　前記リンクテーブルの属性フィールドは、前記各識別子テーブルのタプルの記憶領域の相対的位置を指定するオフセットを含む、データベース構造。
  44. 　請求項４０から４２のうちのいずれか１項に記載のデータベース構造であって、
    　前記リンクテーブルは、行方向に定義された少なくとも１つのタプルと、列方向に定義された少なくとも１つの属性フィールドとを有しており、
    　前記リンクテーブルの属性フィールドは、前記各識別子テーブルのタプルの記憶領域に割り当てられたアドレスを指すポインタを含む、データベース構造。
  45. 　請求項４０から４２のうちのいずれか１項に記載のデータベース構造であって、
    　前記リンクテーブルは、行方向に定義された少なくとも１つのタプルと、列方向に定義された少なくとも１つの属性フィールドとを有しており、
    　前記リンクテーブルの属性フィールドは、前記各識別子テーブルのタプルを一意に表す外部タプル識別子を含み、
    　前記各識別子テーブルの属性フィールドは複数存在し、
    　前記各識別子テーブルの複数の属性フィールドのうち１つの属性フィールドは、当該各識別子テーブルのタプルを一意に表しかつ前記外部タプル識別子に対応する値を持つタプル識別子を含む、データベース構造。
  46. 　請求項４５記載のデータベース構造であって、前記外部タプル識別子は固定長のビット列である、データベース構造。
  47. 　請求項４０から４６のうちのいずれか１項に記載のデータベース構造であって、前記複数の実体データそれぞれの記憶領域を示す位置データと前記複数のデータ識別子との間の対応関係を表す変換テーブルを含むデータベース構造。
  48. 　請求項４０から４６のうちのいずれか１項に記載のデータベース構造であって、前記複数の実体データには、それぞれ、前記複数のデータ識別子と同じ値を持つ検索用データ識別子が付加されている、データベース構造。
  49. 　請求項４０から４８のうちのいずれか１項に記載のデータベース構造であって、前記複数の実体データは可変長データを含む、データベース構造。
  50. 　請求項４０から４９のうちのいずれか１項に記載のデータベース構造であって、
    　前記実体データ群に割り当てられた記憶領域は、複数のパーティション領域に分割され、
    　前記複数のパーティション領域は、それぞれ、前記実体データ群のうち互いに異なるデータ型の実体データを記憶する領域として割り当てられている、データベース構造。
  51. 　請求項４０から４９のうちのいずれか１項に記載のデータベース構造であって、前記複数の実体データにそれぞれ関連した内容を有する複数のサブ実体データを更に含み、
    　前記実体データと当該実体データに関連した内容を有するサブ実体データとが連続的な記憶領域に記憶されている、データベース構造。
  52. 　請求項４０から４９のうちのいずれか１項に記載のデータベース構造であって、前記複数の実体データにそれぞれ関連した内容を有する複数のサブ実体データを更に含み、
    　前記各実体データには、当該各実体データに関連した内容を有する前記サブ実体データの記憶領域の位置を示す位置データが付加されている、データベース構造。
  53. 　請求項４０から４９のうちのいずれか１項に記載のデータベース構造であって、前記複数の実体データにそれぞれ関連した内容を有する複数のサブ実体データを更に含み、
    　前記識別子テーブルは、前記データ識別子に一対一で対応しかつ前記サブ実体データの記憶領域に関連付けられたサブデータ識別子を更に含む、データベース構造。
  54. 　請求項４０から４９のうちのいずれか１項に記載のデータベース構造であって、前記実体データ群に関連した内容を有する少なくとも１つのサブ実体データ群を更に含み、
    　前記実体データ群は、第１の記憶領域に割り当てられ、前記サブ実体データ群は、前記第１の記憶領域とは異なる第２の記憶領域に割り当てられている、データベース構造。
  55. 　データベース管理処理をコンピュータに実行させるコンピュータプログラムであって、
    　前記データベース管理処理は、
    　複数の実体データからなる実体データ群と複数の固定長データのみを有する複数の識別子テーブルとを含むデータベースについてクエリを受信する処理と、
    　前記データベースに対して、当該受信されたクエリに基づいたデータ処理を実行する処理と、
    を備え、
    　前記各識別子テーブルは、行方向に定義された少なくとも１つのタプルと、列方向に定義され、かつ前記複数の実体データそのものをそれぞれ一意に表す複数のデータ識別子を前記固定長データとして含む少なくとも１つの属性フィールドとを有しており、
    　前記データベースは、前記複数の識別子テーブルに加えて前記識別子テーブル間のタプルを関連付けるリンクテーブルを含み、
    　前記データ処理は、前記リンクテーブルおよび前記識別子テーブルを用いることによって実行される、コンピュータプログラム。
  56. 　請求項５５記載のコンピュータプログラムであって、前記識別子テーブルに割り当てられた記憶領域と前記実体データ群に割り当てられた記憶領域とが互いに異なる、コンピュータプログラム。
  57. 　請求項５５または５６記載のコンピュータプログラムであって、前記データ識別子の値は、前記実体データの入力に対して固定長のビット列を出力するハッシュ関数の出力値である、コンピュータプログラム。
  58. 　請求項５５から５７のうちのいずれか１項に記載のコンピュータプログラムであって、
    　前記リンクテーブルは、行方向に定義された少なくとも１つのタプルと、列方向に定義された少なくとも１つの属性フィールドとを有しており、
    　前記リンクテーブルの属性フィールドは、前記各識別子テーブルのタプルの記憶領域の相対的位置を指定するオフセットを含む、コンピュータプログラム。
  59. 　請求項５５から５７のうちのいずれか１項に記載のコンピュータプログラムであって、
    　前記リンクテーブルは、行方向に定義された少なくとも１つのタプルと、列方向に定義された少なくとも１つの属性フィールドとを有しており、
    　前記リンクテーブルの属性フィールドは、前記各識別子テーブルのタプルの記憶領域に割り当てられたアドレスを指すポインタを含む、コンピュータプログラム。
  60. 　請求項５５から５７のうちのいずれか１項に記載のコンピュータプログラムであって、
    　前記リンクテーブルは、行方向に定義された少なくとも１つのタプルと、列方向に定義された少なくとも１つの属性フィールドとを有しており、
    　前記リンクテーブルの属性フィールドは、前記各識別子テーブルのタプルを一意に表す外部タプル識別子を含み、
    　前記各識別子テーブルの属性フィールドは複数存在し、
    　前記各識別子テーブルの複数の属性フィールドのうち１つの属性フィールドは、当該各識別子テーブルのタプルを一意に表しかつ前記外部タプル識別子に対応する値を持つタプル識別子を含む、コンピュータプログラム。
  61. 　請求項６０記載のコンピュータプログラムであって、前記外部タプル識別子は固定長のビット列である、コンピュータプログラム。
  62. 　請求項５５から６１のうちのいずれか１項に記載のコンピュータプログラムであって、
    　前記データベースは、前記複数の実体データそれぞれの記憶領域を示す位置データと前記複数のデータ識別子との間の対応関係を表す変換テーブルを含み、
    　前記データ処理は、前記変換テーブルを用いて前記実体データ群の中から実体データを選択し、この選択結果を用いることによって実行される、コンピュータプログラム。
  63. 　請求項５５から６１のうちのいずれか１項に記載のコンピュータプログラムであって、
    　前記複数の実体データには、それぞれ、前記複数のデータ識別子と同じ値を持つ検索用データ識別子が付加されており、
    　前記データ処理は、前記検索用データ識別子を検索し、この検索結果に基づいて前記実体データを選択し、この選択結果を用いることによって実行される、コンピュータプログラム。
  64. 　請求項５５から６３のうちのいずれか１項に記載のコンピュータプログラムであって、前記データベース管理処理は、前記複数のデータ識別子が不連続な複数の記憶領域に分散して記憶されているとき、前記複数のデータ識別子を記憶部から読み出し、当該読み出されたデータ識別子を、前記識別子テーブルに割り当てられた連続的な記憶領域に書き込むデフラグ処理を更に備える、コンピュータプログラム。
  65. 　請求項５５から６４のうちのいずれか１項に記載のコンピュータプログラムであって、
    　前記実体データ群に割り当てられた記憶領域は、複数のパーティション領域に分割され、
    　前記複数のパーティション領域は、それぞれ、前記実体データ群のうち互いに異なるデータ型の実体データを記憶する領域として割り当てられている、コンピュータプログラム。
  66. 　請求項５５から６４のうちのいずれか１項に記載のコンピュータプログラムであって、
    　前記データベースは、前記複数の実体データにそれぞれ関連した内容を有する複数のサブ実体データを含み、
    　前記実体データと当該実体データに関連した内容を有するサブ実体データとが連続的な記憶領域に記憶されており、
    　前記データ処理は、前記識別子テーブルを検索して前記実体データ群の中から実体データを選択したとき、当該選択された実体データに関連した内容を有するサブ実体データを前記データベースから読み出すことによって実行される、コンピュータプログラム。
  67. 　請求項５５から６４のうちのいずれか１項に記載のコンピュータプログラムであって、
    　前記データベースは、前記複数の実体データにそれぞれ関連した内容を有する複数のサブ実体データを含み、
    　前記各実体データには、当該各実体データに関連した内容を有する前記サブ実体データの記憶領域の位置を示す位置データが付加されており、
    　前記データ処理は、前記識別子テーブルを検索して前記実体データ群の中から実体データを選択したとき、当該選択された実体データに付加された位置データで指定されるサブ実体データを前記データベースから読み出すことによって実行される、コンピュータプログラム。
  68. 　請求項６７記載のコンピュータプログラムであって、前記サブ実体データの記憶領域の位置を示す位置データは、前記サブ実体データの記憶領域の絶対的位置を指定するアドレスである、コンピュータプログラム。
  69. 　請求項６７記載のコンピュータプログラムであって、前記サブ実体データの記憶領域の位置を示す位置データは、前記サブ実体データの記憶領域の相対的位置を指定するオフセットである、コンピュータプログラム。
  70. 　請求項５５から６４のうちのいずれか１項に記載のコンピュータプログラムであって、
    　前記データベースは、前記複数の実体データにそれぞれ関連した内容を有する複数のサブ実体データを含み、
    　前記識別子テーブルは、前記データ識別子に一対一で対応しかつ前記サブ実体データの記憶領域に関連付けられたサブデータ識別子を更に含み、
    　前記データ処理は、前記識別子テーブルを検索して前記実体データ群の中から実体データを選択したとき、当該選択された実体データに関連した内容を有するサブ実体データを前記サブデータ識別子を用いて前記データベースから読み出すことによって実行される、コンピュータプログラム。
  71. 　請求項５５から６４のうちのいずれか１項に記載のコンピュータプログラムであって、
    　前記データベースは、前記実体データ群に関連した内容を有する少なくとも１つのサブ実体データ群を含み、
    　前記データ処理は、当該受信されたクエリに基づいて、前記実体データ群に割り当てられた第１の記憶領域と前記サブ実体データ群に割り当てられた第２の記憶領域とのいずれか一方を選択することによって実行される、コンピュータプログラム。
PCT/JP2009/002359 2008-05-30 2009-05-28 データベースシステム、データベース管理方法、データベース構造およびコンピュータプログラム WO2009144941A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2010514373A JP5392253B2 (ja) 2008-05-30 2009-05-28 データベースシステム、データベース管理方法、データベース構造およびコンピュータプログラム
US12/995,164 US8620880B2 (en) 2008-05-30 2009-05-28 Database system, method of managing database, and computer-readable storage medium

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2008-143767 2008-05-30
JP2008143767 2008-05-30
JP2008249042 2008-09-26
JP2008-249042 2008-09-26

Publications (1)

Publication Number Publication Date
WO2009144941A1 true WO2009144941A1 (ja) 2009-12-03

Family

ID=41376831

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/002359 WO2009144941A1 (ja) 2008-05-30 2009-05-28 データベースシステム、データベース管理方法、データベース構造およびコンピュータプログラム

Country Status (3)

Country Link
US (1) US8620880B2 (ja)
JP (1) JP5392253B2 (ja)
WO (1) WO2009144941A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011209807A (ja) * 2010-03-29 2011-10-20 Nec Corp データベース管理方法、データベースシステム、プログラム及びデータベースのデータ構造
WO2014057616A1 (ja) * 2012-10-11 2014-04-17 日本電気株式会社 情報処理装置
KR20160008176A (ko) * 2013-05-06 2016-01-21 퀄컴 인코포레이티드 속성 필드의 멀티-코어 페이지 테이블 세트
CN109871381A (zh) * 2019-01-22 2019-06-11 积成电子股份有限公司 电网运行数据自适应存储和查询的方法
JP2020514899A (ja) * 2017-03-15 2020-05-21 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ 最適化したビットマップ表現を用いる大規模の関連付けセットの管理

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 日本電気株式会社 データベースシステム、データベース管理方法、データベース構造およびコンピュータプログラム
US9665643B2 (en) * 2011-12-30 2017-05-30 Microsoft Technology Licensing, Llc Knowledge-based entity detection and disambiguation
US9405821B1 (en) * 2012-08-03 2016-08-02 tinyclues SAS Systems and methods for data mining automation
CN103970758A (zh) * 2013-01-29 2014-08-06 鸿富锦精密工业（深圳）有限公司 数据库访问系统及方法
CN104298667A (zh) * 2013-07-15 2015-01-21 中国航天科工集团第三研究院第八三五八研究所 一种适用于高背景星图识别用的导航数据库构建方法
WO2017189921A1 (en) * 2016-04-29 2017-11-02 Dotalign, Inc. Method, apparatus, and computer-readable medium for identifying
US11151111B2 (en) * 2017-11-30 2021-10-19 Futurewei Technologies, Inc. Redistributing table data in a database cluster
CN108268799B (zh) * 2017-12-28 2020-09-01 上海数据交易中心有限公司 数据查询系统和方法、存储介质、终端

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09212528A (ja) * 1995-11-01 1997-08-15 Filetek Inc データベースを記憶する方法、データベースからレコードを検索する方法、および、データベース記憶／検索システム

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6367063B1 (en) * 1998-02-05 2002-04-02 Hughes Electronics Corporation Method and apparatus for selectively performing a plurality of logic operations and memory functions
CA2340008C (en) 1998-08-11 2008-09-23 Shinji Furusho Method and apparatus for retrieving, accumulating, and sorting table-formatted data
JP4428488B2 (ja) 1999-05-31 2010-03-10 株式会社ターボデータラボラトリー 表形式データの結合方法、上記方法を実現するプログラムを記憶した記憶媒体、および、表形式データを結合する装置
JP4227033B2 (ja) 2004-01-20 2009-02-18 富士通株式会社 データベース統合参照装置、データベース統合参照方法およびデータベース統合参照プログラム
US7716180B2 (en) * 2005-12-29 2010-05-11 Amazon Technologies, Inc. Distributed storage system with web services client interface

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09212528A (ja) * 1995-11-01 1997-08-15 Filetek Inc データベースを記憶する方法、データベースからレコードを検索する方法、および、データベース記憶／検索システム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HIDEKAZU TAKAHASHI: "Post RDB", NIKKEI BYTE, no. 251, 1 April 2004 (2004-04-01), pages 38 - 43 *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011209807A (ja) * 2010-03-29 2011-10-20 Nec Corp データベース管理方法、データベースシステム、プログラム及びデータベースのデータ構造
WO2014057616A1 (ja) * 2012-10-11 2014-04-17 日本電気株式会社 情報処理装置
JPWO2014057616A1 (ja) * 2012-10-11 2016-08-25 日本電気株式会社 情報処理装置
KR20160008176A (ko) * 2013-05-06 2016-01-21 퀄컴 인코포레이티드 속성 필드의 멀티-코어 페이지 테이블 세트
KR101708142B1 (ko) 2013-05-06 2017-02-27 퀄컴 인코포레이티드 속성 필드의 멀티-코어 페이지 테이블 세트
JP2020514899A (ja) * 2017-03-15 2020-05-21 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ 最適化したビットマップ表現を用いる大規模の関連付けセットの管理
JP7030831B2 (ja) 2017-03-15 2022-03-07 インターナショナル・ビジネス・マシーンズ・コーポレーション 最適化したビットマップ表現を用いる大規模の関連付けセットの管理
US11372831B2 (en) 2017-03-15 2022-06-28 International Business Machines Corporation Managing large scale association sets using optimized bit map representations
CN109871381A (zh) * 2019-01-22 2019-06-11 积成电子股份有限公司 电网运行数据自适应存储和查询的方法

Also Published As

Publication number Publication date
US8620880B2 (en) 2013-12-31
JP5392253B2 (ja) 2014-01-22
JPWO2009144941A1 (ja) 2011-10-06
US20110082843A1 (en) 2011-04-07

Similar Documents

Publication Publication Date Title
JP5392253B2 (ja) データベースシステム、データベース管理方法、データベース構造およびコンピュータプログラム
US11080277B2 (en) Data set compression within a database system
US11899641B2 (en) Trie-based indices for databases
CN105630409B (zh) 使用存储器内阵列和盘上页结构的双重数据存储
US9805079B2 (en) Executing constant time relational queries against structured and semi-structured data
WO2010084754A1 (ja) データベースシステム、データベース管理方法、データベース構造および記憶媒体
US8700674B2 (en) Database storage architecture
US10296611B2 (en) Optimized rollover processes to accommodate a change in value identifier bit size and related system reload processes
JP5392254B2 (ja) データベースシステム、データベース管理方法、データベース構造およびコンピュータプログラム
CA2723731C (en) Managing storage of individually accessible data units
US20130013606A1 (en) Managing Storage of Data for Range-Based Searching
US20160253382A1 (en) System and method for improving a query response rate by managing a column-based store in a row-based database
US9535940B2 (en) Intra-block partitioning for database management
US10289709B2 (en) Interleaved storage of dictionary blocks in a page chain
WO2019184618A1 (zh) 数据存储的方法、装置、服务器和存储介质
US20220129466A1 (en) Compressing data sets for storage in a database system
US20210326320A1 (en) Data segment storing in a database system
EP1967968B1 (en) Sharing of database objects
CN107273443B (zh) 一种基于大数据模型元数据的混合索引方法
KR100921683B1 (ko) 키-값 데이터 모델을 위한 메모리 페이지 내 데이터저장방법
JP4825504B2 (ja) データ登録・検索システムおよびデータ登録・検索方法
US11868331B1 (en) Systems and methods for aligning big data tables in linear time
CN101458707A (zh) 一种大数据量记录的存储方法
Dean xqerl_db: Database Layer in xqerl
CN117425886A (zh) 具有仅添加数据结构的基于列表的数据搜索

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: 09754450

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 12995164

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2010514373

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: 09754450

Country of ref document: EP

Kind code of ref document: A1