EP2519899A1

EP2519899A1 - Method and arrangement for data storage

Info

Publication number: EP2519899A1
Application number: EP09852855A
Authority: EP
Inventors: Simon Moritz; Jonas BJÖRK; Mattias LIDSTRÖM
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2009-12-29
Filing date: 2009-12-29
Publication date: 2012-11-07
Also published as: EP2519899A4; JP2013516017A; WO2011081580A1

Abstract

A method and arrangement(700) for a hierarchical database (702) comprising a root table and sub-tables in hierarchical levels, each table comprising one or more attributes under which object data can be stored.A configuring function (708) assigns to each sub-table a table identifier TID generated by multiplying a series of prime numbers associated with parent tables of that sub-table. A storing function (704) assigns an object identifier OID to each object in the database such that the table identifiers TID:s of a path of hierarchically connected sub-tables indifferent consecutive levels are encoded into the object identifier OID, and stores data on that object in the connected sub-tables in the table path.

Description

METHOD AND ARRANGEMENT K) R DATA STORAGE

Technical field

[0001] The invention relates generally to a method and arrangement for providing efficient storage and retrieval of data in a database.

Background

[0002] When large amounts of data are to be stored in a database for different objects, it is useful to organize the data in a way that can facilitate retrieval of relevant data when receiving data queries or requests referring to particular objects. The stored data may relate to any type of object information that can be arranged logically in different classes or categories of a hierarchical structure. The term "object' is used throughout this description, although other terms could also be used such as items, assets, entities, etc. Some practical examples of objects occurring in such databases are media items, products for sale, telecommunication subscribers, etc.

[0003] A plurality of attributes are typically relevant for each object, and data referring to such attributes is stored in the database available for retrieval in response to data queries. In practice, the attributes typically form columns in one or more tables in the database. In this description, the term "attribute" represents any subject, aspect or characteristic that may be relevant for describing an object An attribute may be either generic or more specific.

[0004] Eor example, media items may be divided into the classes "Moving Images" and "Still Images", while "Moving Images" may in turn be divided into the classes "Movies", "Sports", "Documentaries", and so forth. In this way, the different classes can form a hierarchical structure which can be represented by tables in the database. Each class may be associated with one or more attributes relevant for that class. [0005] Jig. 1 illustrates schematically a hierarchical structure of different classes in which data for objects can be logically organized. On top of the hierarchy is a "Raotclass" with attributes denoted "Info 1", "Info 2", "Info 3"... These attributes refer to general or "abstract' data relevant for all objects in the database, e.g. title, description, language, input date, etc., using the example of media items. An object identity "Object HT is also specified in a field of this class to identify each object, which can be used as a primary key for data searches. By way of example, the R)otclass may be called the "Assetclass".

[0006] The next level comprises two sub-classes A and B with attributes denoted "Info Al", "Info A2", "Info A3"... and "Info Bl", "Info B2", "Info B3"...,

respectively. The attributes in each sub-class are relevant only for objects that fit into that sub-class. Again using the example of media items, sub-class A may refer to Moving Images and the attributes therein may refer to encoding, duration, color, etc, while sub-class B referring to Still Images may have other relevant attributes such as width, height, resolution, format, etc.

[0007] In a similar manner, sub-classes AA and AB in the next level are

organized under sub-class A and may refer to Movies and Sports, respectively, each having one or more sub-class specific attributes. All sub-classes A, B, AA, BB... have the Object!) field to identify the objects fitting into the respective sub-class.

[0008] Today, relational databases are typically used for holding data that can be organized in the above class-based hierarchical manner. The mapping of objects or class definitions to database tables can however be associated with problems, sometimes referred to as "object-relational impedance mismatch". Below, three different approaches commonly used in the field of relational databases, are briefly described:

[0009] 1) A single table is used for all sub-classes and attributes in the entire class hierarchy, and the table thus comprises columns or the like for all attributes used in me database. In the example of Hg. 1, me table would contain columns for all attributes Wo 1-3, Wo A1-A3, Wo B1-B3, Wo AA1-AA3, Wo AB1-AB3... in all sub-classes, tiius typically resulting in a great number of columns in the table.

Thereby, a data query requires only one table search when retrieving data for an object On the other hand, the database readability and performance may be poor since the single table will typically be very large. Moreover, many columns will be empty, i.e. contain null values, since many attributes are often irrelevant for the objects. A lot of space in the database will thus be left unused and the database will be of undue size. Additional discriminatory information may also be needed in the database to indicate the type of object

[00010] 2) One table is used for each sub-class and contains all attributes relevant for objects that fit into that sub-class, including attributes in all higher classes to which that sub-class is connected. In the example of Hg. 1 , a table for sub-class AA would contain columns for attributes Wo AA1-AA3, Wo A1-A3, Wo 1-3..., while a table for sub-class AB would contain columns for attributes Wo AB1-AB3 , Wo Al- A3, Wol-3. An advantage with this approach is thatall data for an object is stored in one and the same table making searches in other tables unnecessary. On the other hand, it is not known in which table data is stored for an object, and the tables must therefore be searched one by one until data is found for the searched object Moreover, many attributes will occur in multiple tables, such as in the example above, and data will therefore be duplicated thus creating much

redundancy and the database will be of undue size in this approach as well.

[00011] 3) One table is used for each sub-class and contains attributes of that sub- class only, thus avoiding redundancy and data duplication However, in this approach it is not evident how the different classes are connected to one another in the hierarchical structure. When performing a search for data of an object, tables can be selected for search and others can be ignored using knowledge of the hierarchy although it is not known where to start searching, and many table searches will still produce null results which could be quite time consuming and a waste of processing resources.

[00012] In the above three approaches of using tables in the database, only the latter one requires joining information between the tables. However, none of them is able to provide both efficient use of storage space and rapid searches, as explained above, lis thus a problem that great amounts of stored data mustbe searched in order to retrieve relevant data in response to data queries or requests referring to particular objects, which is time-consuming and requires much processing resources. Another problem is that the above-described redundancy and duplication of stored data result in excessive size of the database.

Summary

[00013] lis an objectof the invention to address atleast some of the problems outlined above, lis also an object to obtain a database solution that can avoid duplication and redundancy in the database, at the same time avoiding undue processing delays and load for searching the database, lis possible to achieve these objects and others by using a method and an arrangement as defined in the attached independent claims.

[00014] According to one aspect, a method is provided for handling object-related data in a hierarchical database comprising a root table and a plurality of predefined sub-tables organized in multiple hierarchical levels below said root table, each table comprising one or more attributes under which object data can be stored. In this method, a table identifier TID is assigned to each sub-table, and the table identifier TID is generated by multiplying a series of prime numbers associated with parent tables of said sub-table. Further, an object identifier OID is assigned to each object in the database such that the table identifiers TID:s of a path of hierarchically connected sub-tables in different consecutive levels are encoded into me object identifier OK). The data on me object is stored in me connected sub- tables in me table path, where appropriate.

[00015] Thereby, duplication of stored data and redundancy in the database due to repeated attributes in plural tables can be avoided. At the same time, searching for data can be limited to those tables that are valid for the searched object and where data on the object is expected to be found by encoding the valid table path into the object identifier OK), such that the processing delays and load for searching the database can be miriimised.

[00016] According to another aspect, an arrangement is provided thatis configured to handle object-related data in the above hierarchical database. The database arrangement comprises a configuring function adapted to assign a table identifier ΊΚ) to each sub-table, generated by multiplying a series of prime numbers associated with parent tables of said sub-table. The database arrangement also comprises a storing function adapted to assign an object identifier OK) to each object in the database, such that the table identifiers TK):s of a path of hierarchically connected sub-tables in different consecutive levels are encoded into the object identifier OK), and to store data on said object in the connected sub-tables in the table path.

[00017] The above method and database arrangement may be configured and implemented according to different embodiments. In one embodiment, the table identifier IK) is generated for a sub-table by multiplying the parent table identifier HD of that sub-table's parent table in an adjacent level with a next available prime number of said parent table. Thereby, a table path can readily be encoded in a single number used as object identifier OK), by means of factorization of prime numbers.

[00018] In another embodiment, data relating to an object is stored in the database by determining a table path with an identified sub-table relevant for said object and parent tables hierarchically connected to said sub-table, assigning an objectidentifier OID to the object computed from the table identifier HD of the determined relevant sub-table, and storing the data and the objectidentifier OD in the tables of said path.

[00019] The object identifier OK) can be computed as: OID = 2^k · n + HD, where k is an integer selected to set 2^k as a maximum value of the table identifier HD in the database hierarchy, and n is a sequence number for objects in the determined relevant sub-table. In Ibis way, the table identifier HD is encoded in the object identifier OK) while all parent table identifiers HD:s can be determined from that table identifier HD by prime number factorization thereof

[00020] In further embodiments, when receiving a data query referring to an object identifier OK) of a requested object, object-related data can be retrieved from the database by computing from the received object identifier OK) a table identifier HD of a sub-table relevant for the requested object The table path encoded into the received object identifier OK) is then determined by computing parent table identifiers HD of successive levels until the root table is reached. Object data is then fetched from the tables in the determined table path, and the fetched data is finally returned in response to the data query.

[00021] The table identifier TK) of the sub-table relevant for the requested object may be computed as: 11L⁾ = mod (OID, 2^k), where k is an integer selected to set 2^k as a maximum value of the table identifier HD in the database hierarchy and OK) is the received object identifier. Further, each parent table identifier HD can be computed by dividing a current table identifier HD with its greatest prime factor.

[00022] In further embodiments, a new sub-table is added to the database by computing a table identifier HD for the new sub-table by multiplying the table identifier HD of its parent table by the next available prime number. If the computed table identifier TID is not below 2 ^k where k is an integer selected to set 2 ^k as a maximum value of the table identifier TID in the database hierarchy, k is

incremented by 1 and the object identifiers OID:s of objects stored in the database are updated according to the new k The new sub-table can be added to the database using the computed table identifier TID.

[00023] iurther possible features and benefits of this solution will become apparent from the detailed description below.

Bief description of drawings

[00024] The invention will now be described in more detail by means of exemplary embodiments and with reference to the accompanying drawings, in which:

[00025] Jig. 1 illustrates an exemplary hierarchical structure with different classes of object information.

[00026] Jig. 2 is a schematic block diagram illustra ting how a data query can be handled by a logical search function, according to one possible embodiment

[00027] Jig. 3 is a schematic representation of an exemplary database structure, according to another possible embodiment

[00028] Jig. 4 is a flow chart with steps performed by a logical storing function to store object data in a database, according to further exemplary embodiments.

[00029] Jig. 5 is a flow chart with steps performed by a logical search function to search for object data in a database, according to further exemplary embodiments.

[00030] Jig. 6 is a flow chart with steps performed by a logical corifiguring function to add a new table in a database, according to further exemplary embodiments. [00031] Jig. 7 is a block diagram illustra ting in more detail an arrangement with logical storing, search and configuring functions connected to a database, according to further exemplary embodiments.

Detailed description

[00032] Eriefly described, a solution is provided to enable efficient storage and rapid retrieval of object data from a database with hierarchically arranged tables associated with different logical classes or categories. Each table comprises one or more attributes arranged as columns or equivalent, under which data can be stored for different objects. The database can be configured basically according to approach 3) above, i.e. using just one table for each sub-class which contains attributes of that sub-class only, where duplication of attributes and stored data in multiple tables is not necessary. The database is thus logically organized in a hierarchical structure of tables, e.g. according to the scheme shown in Jig. 1, including a root table at a top level and multiple sub-tables in successively lower layers in the hierarchy. According to terminology used in this description, a "parent table" is a table to which one or more subordinate sub-tables are connected in the hierarchical structure. Thus, each sub-table is connected to a parent table.

[00033] In the present inventive solution, an object identifier "O ID" is assigned to each object stored in the database where identities of all interconnected sub-tables relevant for a particular object are effectively encoded into the OID of thatobject Thereby, the tables that are relevant for searching can be determined solely from the OID of a requested object while no further tables need to be searched, which will basically avoid any unnecessary searching. At the same time, no table(s) relevant to a searched object will be missed in the search

[00034] jrthermore, the tables in the database have been assigned table identifiers, "TIDs", which are numbers thatcan be encoded into the object identifiers, OlD.s, as follows. Each TID is generated by multiplying a series of prime numbers, such that the TID of a sub-table connected to a parent table is generated by multiplying the TID of the parent table with a "next available prime number", i.e. a prime number that has not been used yet to generate any other sub-table connected to that parent table, which will be described in more detail and by means of examples below.

[00035] Hence, all sub-tables connected to a parent table must have a prime number factor greater than the parent table's greatest prime number factor, and each prime number can only be used once for a parent table to generate its subordinate sub-tables, ibr example, if prime numbers 7, 11 and 13 have been used to generate TID:s of three particular sub-tables connected to a particular parent table having a TID = 5, the next available prime number is 17 and the TID of a new sub-table is generated by multiplying the parent table's TID with 17 resulting in a TID = 5 · 17 = 85. The other three sub-tables connected to the parent table with TID = 5 thus have the following TID:s: ΊΚ) = 5 · 13 = 65, ΊΚ) = 5 · 11 = 55, and ΊΚ) = 5 · 7 = 35, respectively. Ey generating TID:s in this way, each table in the database will be assigned a unique TID.

[00036] lis assumed thatthe database structure and its hierarchy of tables have been predetermined and are thus known, and that it can be logically determined which (lowest) sub-table is the most relevant for a given object Data of the object may also be stored in the parent tables to which the lowest and most relevant sub- table is connected, thus forming a path of interconnected tables in consecutive hierarchical levels where all tables in that table path are valid for the given object and should therefore be searched whenever a data query is made referring to the OK) of thatobject The process of logically identifying the most relevant sub-table for an object when storing data is however outside the scope of this invention. [00037] An OK) can thus be assigned to an object by first logically identifying or detemining which sub-table is most relevant for the object, and then using the TID of that sub-table to generate the OK) for the object as:

[00038] OJD = 2^k · n + HD (1)

[00039] In equation (1), k is an integer selected to set 2^k as a maximum value of the ΊΚ) in the entire database hierarchy, and n is a sequence number for objects in the determined relevant sub-table. Thus, a first object stored in sub-table TID may have n = 1, a second object in that sub-table may have n = 2, and so forth. The parameter k is in fact the number of bits required to store the maximum value of ΊΚ). ibr example, if k = 8, the maximum TID = 256, since 8 binary bits can be used to represent the value 256. I^" a TK) > 256 is needed for a new table in the database, k must be incremented by 1 which will in turn affect the OK):s that have already been generated for stored objects. As a result, whenever k is incremented to give "room" for higher TK) values in the database, the OK):s of objects already stored in the database mustbe updated according to the new k value in equation (1).

[00040] It will now be described how a data query can be handled by a logical search function, with reference to Jig. 2. The search function 200 is configured to search for object data in a hierarchical database 202 upon receiving a search query or request for object data, as follows. The database 202 is basically configured as described above.

[00041] When the search query is received, referring to an OK) of a searched object, the search function 200 will determine the greatest TK) value encoded in the received OK), illustrated as a block 204, presumably referring to a (the lowest) sub- table that is most relevant for the requested object Since all TK):s of the database have been generated by mulnplying prime numbers as described above, the greatest TK) value encoded in OK) can be computed as: [00042] HD = mod (OID, 2^k) (2)

[00043] Where "mod" is a modulus operation dete mining the residual integer after dividing O E) with 2^k.

[00044] Then, the search function 200 extracts all lower TID:s in a path of interconnected sub-tables by identifying the prime numbers that generate the first TID, illustrated as a block 206. This operation is possible since each sub-table TID has been generated from its parent table TID, that is by multiplying the TID of the parent table with a "next available prime number", as described above. Basically, the TID determined by (2) in block 204 above is prime number facto rized in block 206.

[00045] When all table TID:s in the table path have been determined, a data search is accordingly performed for the object in database 202, illustrated as a block 208, and this search can thus be limited to the tables in the determined path only, since no data of that object can be expected to occur in any other tables outside the path. The determined table path is thus valid for the object as encoded in its OID. Enally, the search results, i.e. data found, can be returned to the querying party, illustrated as a block 210.

[00046] Jig. 3 illustrates a TID scheme for a database organized with a

hierarchical structure of tables, including a roottable at a top level 300 and multiple sub-tables in successively lower layers 302, 304, 306,... in the hierarchy. TID:s of the tables are given within the shown spots and the prime numbers used for generating underiying TID:s are given at respective connection arrows. The root table has TID = 1, and the three shown sub-tables in the level 302 below has TID:s generated by multiplying 1 with a series of prime numbers, i.e. 2, 3 and 5 , resulting in TID:s 2, 3 and 5, respectively. In the next level 304, four sub-tables are connected to the parent table 2, having TID:s generated by multiplying 2 with a series of prime numbers, i.e. 3, 5, 7 and 11, resulting in TID:s 6, 10, 14 and 22, respectively.

[00047] A similar calculation of TID: s has been made for four sub-tables connected to the parent table 3, having TID:s generated by multiplying 3 with a series of prime numbers, i.e. 5, 7, 11 and 13, resulting in HD:s 15 , 21, 33 and 39, respectively, and so forth. It should be noted that each TID is generated by multiplying the TID of the parent table with a next available prime number, i.e. a prime number that has notbeen used for any other sub-table connected to that parent table. Thus, each prime number used for generating an underiying TID is used just once for each parent table, hence the term "next available prime number", ensuring thatthe TID:s will be unique for all tables in the database.

[00048] An exemplary procedure for storing data in a database relating to a new object, will now be described with reference to the flow chart in Jig. 4. This procedure may be executed by a "data storing function" or similar, connected to the database in a database arrangement lis assumed thatthe database comprises a root table and a plurality of predefined sub-tables organized in multiple hierarchical levels below the roottable, and that each table comprises one or more attributes under which object data can be stored, lis also assumed that a table identifier TID has been assigned to each sub-table, which has been generated by multiplying a series of prime numbers associated with respective parent tables, as described above.

[00049] a first step 400, data related to the object is received for storage in the database. In a next step 402, the sub-table most relevant for the object and its assigned TID are basically received at the data storing function. Hentifying the most relevant sub-table for the object is a logical operation that depends on the nature of the object and the definitions of the predefined sub-tables in the database. The operation of identifying the relevant sub-table can be made more or less manually by an administator, or automatically according to a preprogrammed logic, e.g. based on the type of object and/ or me data to be stored. The details of this operation is however outside me scope of mis embodiment

[00050] Once me most relevant sub-table and its assigned TID have been settled, a valid table path with interconnected parent tables in successively higher layers in me hierarchy, is determined from me relevant sub-table's TID in a following step 404. In this description, a TID for a parent table is also denoted Rirent table Identifier "HD\ The parent tables can be determined such mat each parent table identifier HD is computed, one by one, by dividing a current table identifier TID with its greatest prime factor. Using me exemplary table structure in Jig. 3, if me most relevant table has been identified as, say, me one having TID = 231, which is located in me fourth hierarchical level 306, its greatest prime factor can be determined as 11 resulting in me parent table with TID = 231/ 11 = 21. This sub- table in turn has 7 as its greatest prime factor, resulting in me next parent table with TID = 21/ 7 = 3 , and so forth. This determination of table path is basically completed when me roottable has been reached.

[00051] a further step 406, an OID is assigned to me object and the OID is computed by means of equation (1) above, using me TID of me most relevant sub- table as input, which was identified in step 402 above. As said above, k is an integer selected to set 2 ^k as a maximum value of me TID in me entire database hierarchy, while n is a sequence number for objects in me determined relevant sub- table. The sequence number n is set for me object as a unique object number in me table, e.g. a next available number not used for any other previous object in mat table. Enally, in a step 408, me object data received in step 400 and me OK) computed and assigned in step 406, are stored in the tables of me table path determined in step 404, where appropriate. It should be noted mat it is not necessary to fill all me attributes in the tables of the path with data in this step, depending on what data is available for storage.

[00052] An exemplary procedure for searching data in a database relating to a new object, will now be described with reference to the flow chart in Jig. 5. This procedure may be executed by a "data searching function" or similar, connected to the database in a database arrangement Again, it is assumed that the database comprises a roottable and sub-tables below the roottable, each table comprising one or more attributes, lis also assumed that a table identifier TID has been assigned to each sub-table, generated by multiplying prime numbers as described above.

[00053] a first step 500, a data query is received from a querying parly, the query referring to an OK) of an object In a next step 502, a TID of the most relevant table for the object, is computed from the received OK), by using equation (2) above which thus results in the highest ΊΚ) value encoded in the OK), ibr example, if k has been set to 10, 2^k = 1024. ff the received OK⁾ is 4369,

mod(OID,2^k)= 273, being the residual integer as OK⁾/ 2^k = 4369/ 1024 = 4 + 273/ 1024. Hence, IK) = 273, which incidentally also occurs in Hg. 3 as the second table in level 306. Since 13 is the greatestprime factor of 273, the parent table ofHD = 273 can be identified as HD = 273/ 13 = 21.

[00054] h a further step 504, the greatestprime factor of the computed TK) is determined and the nextHD of the parent table connected to the first sub -table is computed therefrom by dividing the above computed IK) with its greatestprime factor. It is then deterained if the roottable has been reached yet, in a step 506. If not, the process returns to step 504 where the nextHD is computed by in turn dividing the above computed HD with its greatestprime factor. Steps 504 and 506 are thus repeated to find the parent tables, one by one, until the roottable has been reached. [00055] When it is found thatthe roottable has finally been reached in step 506, determination of the valid table path has been completed and object data can be searched and fetched from the tables in the path according to the computed

TIE)/ HD:s, in a next step 508. It is notnecessary to search any other tables than those in the determined table path, as explained above. Then, the fetched data of the object is returned to the querying parly, in a final shown step 510.

[00056] An exemplary procedure for expanding the database by adding a new table, will now be described with reference to the flow chart in Jig. 6. This procedure may be executed by a "database corifiguring function" or similar, connected to the database in a database arrangement Again, it is assumed thatthe database comprises a roottable and sub-tables below the roottable, each table comprising one or more attributes, lis also assumed that a table identifier TID has been assigned to each sub-table, generated by multiplying prime numbers as described above.

[00057] In this example, it is further assumed that it is desirable to add a new table to the table hierarchy, e.g. when objects liaving a new characteristic in some respect not fitting with the existing table definitions, are to be stored in the database, or when a particular existing table is populated with very large amounts of stored data and needs to be subdivided for facilitating the searches therein. In a first shown step 600 , information on the new table is generally received at the database corifiguring function, which has been defined e.g. by setting a name for the table and defining attributes, the details of which are somewhat outside the scope of this solution. It has also been determined where in the table hierarchy the new table shall be situated, i.e. its parent table has been determined.

[00058] In a next step 602, a TID is generated for the new table, by multiplying the next available prime number with the HD of the parent table, in the manner described above, lis then checked in a following step 604, whether the generated HD does not amount to me parameter 2 ^k which has been set as a maximum value of me TID in me entire database hierarchy.

[00059] ffthe generated TID equals or exceeds the parameter 2 ^k in step 604, k is incremented by one, i.e. k = k + 1 , to make more "room" for greater TID: s in the database, and the OID:s already stored in the database must then be updated based on the new incremented k, as shown by a step 606. As described above, each OID is computed according to equation (1). On me other hand, if the generated TID does not equal or exceed the parameter 2 ^k in step 604, the current value of k can be imintained and no updating of OID:s are necessary, thus excluding step 606. Enally, the new table can be added to the database, in a last shown step 608.

[00060] An arrangement for a database will now be described in more detail with reference to the block diagram of Jig. 7. The database arrangement 700 is configured to handle object-related data in a hierarchical database 702 comprising a root table and a plurality of predefined sub-tables organized in multiple

hierarchical levels below the roottable, not shown in this figure. Each table comprises one or more attributes under which object data can be stored. The database arrangement 700 may be used to accomplish any of the above-described procedures and embodiments. The various functions therein are called "modules" in this description, although they could also be seen as units, blocks, elements or components.

[00061] The shown database arrangement comprises a storing function 704, a search function 706 and a configuring function 708. The configuring function 708 is adapted to assign a table identifier TID to each sub-table, generated by

multiplying a series of prime numbers associated with parent tables of that sub-table. The storing function 704 is adapted to assign an object identifier OK) to each object in the database such that the table identifiers TK):s of a path of hierarchically connected sub-tables in different consecutive levels are encoded into me object identifier OK), and to store data on the object in the connected sub -tables in me table path.

[00062] The configuring function 708 is further adapted to generate a table identifier TID for a sub-table by multiplying the parent table identifier HD of that sub- table's parent table in an adjacent level with a next available prime number of the parent table, ibr example, me TK) = 399 in level 306 as shown in Hg. 3 is generated by multiplying the HD = 21 with the next available prime number 19 in this case, i.e. 21 · 19 = 399.

[00063] In ilg. 7, the storing function 704 includes a determining module 704a adapted to determine a table path with an identified sub-table and parent tables hierarchically connected to that sub-table, an assigning module 704b adapted to assign an object identifier OK) to the object computed from the table identifier ΊΚ) of the determined relevant sub-table, and a storing module 704c adapted to store the data and the object identifier OK) in the tables of the path.

[00064] The assigning module may be further adapted to compute the object identifier OK) as: OK) = 2^k · n + TID, where k is an integer selected to set 2^k as a iraximum value of the table identifier ΊΚ) in the database hierarchy, and n is a sequence number for objects in the determined relevant sub-table.

[00065] The shown database arrangement also comprises a search function 706 adapted to determine which tables to search when a data query is received referring to an object identifier OK) of a requested object, based on the received object identifier OK). The search function 706 includes a computing module 706a adapted to compute from the received object identifier OK) a table identifier ΊΚ) of a sub-table that is the most relevant for the requested object The search function 706 further includes a detennining module 706b adapted to determine a table path encoded into the received object identifier OK), by computing parent table identifiers HD of successive levels until the root table is reached, and a retrieving module 706c adapted to fetch object data from the tables in the determined table path, and to return the fetched data in response to the data query.

[00066] The computing module 706a may be further adapted to compute the table identifier HD of the most relevant sub-table as: 11L⁾ = mod (OID, 2^k), where k is an integer selected to set 2 ^k as a rmximum value of the table identifier HD in the database hierarchy and OK) is the received object identifier. The determining module 706b may be further adapted to compute each parent table identifier HD by dividing a current table identifier HD with its greatest prime factor.

[00067] The configuring function 708 includes a computing module 708a adapted to compute a table identifier HD for a new sub-table to be added to the database, by multiplying the table identifier HD of its parent table by a next available prime number of the parent table. The configuring function 708 also includes an updating module 708b. I^" the computed table identifier HD is notbelow 2^k where k is an integer selected to set 2 ^k as a iraximum value of the table identifier HD in the database hierarchy, the updating module 708b is adapted to increment k by 1 and update the object identifiers OK):s of objects stored in the database according to the new k The configuring function 708 also includes an adding module 708c adapted to add the new sub-table to the database using the computed table identifier HD.

[00068] It should be noted thatilg. 7 merely illustrates various functional units or modules in the database arrangement in a logical sense, although the skilled person is fiiee to implement these functions in practice using suitable software and hardware means. Thus, the invention is generally not limited to the shown structures of the functions 704, 706 and 708, respectively, while its functional modules 704a-c, 706a-c and 708a-c may be configured to operate according to the metiiods and procedures described above for Jig's 2-6, where appropriate.

[00069] While tiie invention has been described with reference to specific exemplary embodiments, the description is generally only intended to illustrate the inventive concept and should not be taken as limiting the scope of the invention The invention is defined by the appended claims.

Claims

CIA S

1. A method of handling object-related data in a hierarchical database comprising a root table and a plurality of predefined sub-tables organized in multiple hierarchical levels below said roottable, each table comprising one or more attributes under which object data can be stored, wherein

- a table identifier TID is assigned to each sub-table, generated by multiplying a series of prime numbers associated with parent tables of said sub-table, and

- an object identifier OK) is assigned to each object in the database such that the table identifiers TK):s of a path of hierarchically connected sub-tables in different consecutive levels are encoded into the object identifier OK), data on said object being stored in the connected sub-tables in the table path

2. A method according to claim 1, wherein said table identifier IK) is generated for a sub-table by multiplying the parent table identifier HD of that sub- table's parent table in an adjacent level with a next available prime number of said parent table.

3. A method according to claim 1 or 2, comprising the following steps executed to store data in the database relating to an object

- detenmning a table path with an identified sub-table relevant for said object and parent tables hierarchically connected to said sub-table,

- assigning an objectidentifier OID to the object computed from the table identifier IK) of the determined relevant sub-table, and

- storing the data and the object identifier OK) in the tables of said path

4. A method according to claim 3, wherein said object identifier OK) is computed as: OID = 2^k · n + HD, where k is an integer selected to set 2 ^k as a maximum value of the table identifier TID in the database hierarchy, and n is a sequence number for objects in the determined relevant sub-table.

5. A method according to any of claims 14, further comprising the following steps executed to retrieve object-related data from the database when receiving a data query referring to an object identifier OK) of a requested object

- computing from the received object identifier OK) a table identifier ΊΚ) of a sub- table relevant for the requested object,

- detemtining the table path encoded into the received object identifier OK) by computing parent table identifiers HD of successive levels until the root table is reached,

- fetching object data from the tables in the determined table path, and - returning the fetched data in response to the data query.

6. A method according to claim 5 , wherein the table identifier TID of the sub- table relevant for the requested object is computed as: HD = mod (OLD, 2^k), where k is an integer selected to set 2^k as a maximum value of the table identifier TID in the database hierarchy and OK) is the received object identifier.

7. A method according to claim 5 or 6, wherein each parent table identifier HD is computed by dividing a current table identifier ΊΚ) with its greatest prime factor.

8. A method according to any of claims 1-7, further comprising the following steps executed to add a new sub-table to the database:

- computing a table identifier ΊΚ) for the new sub-table by multiplying the table identifier HD of its parent table by the next available prime number, - if the computed table identifier TID is not below 2^k where k is an integer selected to set2^k as a maximum value of the table identifier TID in the database hierarchy, incrementing kby 1 and updating the object identifiers OID:s of objects stored in the database according to the new k, and

- adding the new sub-table to the database using the computed table identifier TID.

9. A database arrangement (700) configured to handle object-related data in a hierarchical database (702) comprising a root table and a plurality of predefined sub-tables organized in multiple hierarchical levels below said root table, each table comprising one or more attributes under which object data can be stored, wherein the database arrangement comprises:

- a configuring function (708) adapted to assign a table identifier TID to each sub- table, generated by multiplying a series of prime numbers associated with parent tables of said sub-table, and

- a storing function (704) adapted to assign an object identifier OK) to each object in the database such that the table identifiers TK):s of a path of hierarchically connected sub-tables in different consecutive levels are encoded into the object identifier OK), and to store data on said object in the connected sub-tables in the table path.

10. An arrangement according to claim 9, wherein the configuring function (708) is further adapted to generate said table identifier ΊΚ) for a sub-table by multiplying the parent table identifier HD of that sub-table's parent table in an adjacent level with a next available prime number of said parent table.

11. An arrangement according to claim 9 or 10, wherein the storing function (704) includes: - a determining module (704a) adapted to determine a table path with an identified sub-table relevant for said object and parent tables hierarchically connected to said sub -table,

- an assigning module (704b) adapted to assign an object identifier OK) to the object computed from the table identifier TID of the determined relevant sub-table, and

- a storing module (704c) adapted to store the data and the objectidentifier OD in the tables of said path.

12. An arrangement according to claim 11, wherein the assigning module is further adapted to compute said object identifier OK) as: OID = 2^k · n + JUL), where k is an integer selected to set 2^k as a rmximum value of the table identifier IK) in the database hierarchy, and n is a sequence number for objects in the determined relevant sub-table.

13. An arrangement according to any of claims 9-12, further comprising a search function (706) adapted to determine which tables to search when a data query is received referring to an object identifier OK) of a requested object, based on the received object identifier OK).

14. An arrangement according to claim 13, wherein the search function (706) includes:

- a computing module (706a) adapted to compute from the received object identifier OK) a table identifier IK) of a sub-table relevant for the requested object,

- a detemtining module (706b) adapted to determine a table path encoded into the received object identifier OK), by computing parent table identifiers HD of successive levels until the root table is reached, and - a retiieving module (706c) adapted to fetch object data from the tables in the determined table path, and to return the fetched data in response to the data query.

15. An arrangement according to claim 14, wherein the computing module (706a) is further adapted to compute the table identifier TID of the sub-table relevant for the requested object as: 11L⁾ = mod (OLD, 2^k), where k is an integer selected to set2^k as a maximum value of the table identifier TID in the database hierarchy and OID is the received object identifier.

16. An arrangement according to claim 14 or 15, wherein the detern±iing module (706b) is further adapted to compute each parent table identifier HD by dividing a current table identifier TID with its greatest prime factor.

17. An arrangement according to any of claims 9-16, wherein the configuring function (708) includes:

- a computing module (708a) adapted to compute a table identifier TID for a new sub-table to be added to the database, by multiplying the table identifier HD of its parent table by a next available prime number of said parent table,

- an updating module (708b) adapted to, if the computed table identifier TID is not below 2^k where k is an integer selected to set 2^k as a maximum value of the table identifier TID in the database hierarchy, increment k by 1 and update the object identifiers OID:s of objects stored in the database according to the new k, and

- an adding module (708c) adapted to add the new sub-table to the database using the computed table identifier TID.