Data management method and system based on vector database and computing equipment

Abstract

The invention discloses a data management method based on a vector database. The method comprises the following steps: receiving a data processing request carrying a context name and an entity name from a client; based on the context of the target database and the type of the target entity, performing relation persistence operation on the structured field in the request body; performing text preprocessing on an embeddable field in the request body, generating a corresponding embedding vector, and writing the embedding vector and corresponding metadata information into a vector database; and when the data processing request is a data query request, performing permission and quota verification on the data query request, querying the relational database and the vector database according to a permission and quota verification result to obtain a candidate primary key set, and returning the candidate primary key set to the relational database to generate a response data list. According to the method, authority and quota, relation persistence, vector writing and return table retrieval can be unified for data management, transaction consistency and semantic retrieval capability are considered, and data security can be improved.

Description

Technical Field

[0001] This invention relates to the field of data management technology, and in particular to a data management method, data management system and computing device based on a vector database. Background Technology

[0002] Existing enterprise-level data platforms generally use relational databases for CRUD operations. While these provide transactional consistency and complex constraints, they lack sufficient support for the requirement of "finding records semantically." Pure vector retrieval systems, although possessing semantic recall capabilities, lack stable transaction and table lookup mechanisms, resulting in a fragmented "write-retrieve-table lookup-authorization" chain and creating compatibility challenges for model dimensional upgrades. Therefore, there is an urgent need for a data management solution that unifies permissions and quotas, relation persistence, vector writes, and table lookup retrieval without sacrificing generality.

[0003] Therefore, a data management method based on vector databases is needed to solve the problems existing in the above technical solutions. Summary of the Invention

[0004] Therefore, the present invention provides a data management method and data management system based on a vector database to solve or at least alleviate the problems mentioned above.

[0005] According to one aspect of the present invention, a data management method based on a vector database is provided, executed on a server side. The method includes: receiving a data processing request from a client carrying a context name and an entity name; locating the corresponding target database context based on the context name; and obtaining the corresponding target entity type based on the entity name. When the data processing request is a data creation request or a data update request, performing relational persistence operations on the structured fields in the request body of the data processing request based on the target database context and the target entity type to update the relational database. Preprocessing the embeddable fields in the request body of the data processing request to generate corresponding embedding vectors, and writing the embedding vectors and corresponding metadata information into a vector database, wherein the metadata information includes a primary key, tenant identifier, tag set, and business status. When the data processing request is a data query request, performing permission and quota verification on the data query request, and querying the relational database and the vector database based on the permission and quota verification results to obtain a candidate primary key set and returning it to the relational database to generate a response data list.

[0006] Optionally, in the data management method based on a vector database according to the present invention, performing relation persistence operations on the structured fields in the request body of the data processing request based on the target database context and the target entity type includes: performing deserialization processing on the structured fields in the request body of the data processing request based on the target entity type to obtain an entity instance of the target entity type; and performing relation persistence operations on the entity instance based on the target database context.

[0007] Optionally, in the data management method based on a vector database according to the present invention, performing relation persistence operations on the entity instance based on the target database context includes: attaching the main entity corresponding to the entity instance to the target database context; traversing each navigation attribute of the main entity and recursively adding each navigation sub-entity corresponding to each navigation attribute to the tracking set of the target database context; using an ORM framework to write the entity instance into the corresponding table column in the relational database according to the mapping relationship between the entity type and the table in the relational database, and generating or updating the corresponding table row record and the primary key corresponding to the entity instance.

[0008] Optionally, in the data management method based on a vector database according to the present invention, before writing the entity instance into the corresponding table column in the relational database according to the mapping relationship between entity type and table in the relational database using the ORM framework, the method includes: traversing and determining whether each navigation attribute corresponding to each navigation sub-entity recursively added to the tracking set of the target database context is allowed to be null; if the navigation attribute is not allowed to be null, determining whether the value of the navigation attribute is null; if the value of the navigation attribute is null, stopping the writing of the entity instance into the corresponding table column in the relational database.

[0009] Optionally, in the data management method based on a vector database according to the present invention, the permission and quota verification of the data query request includes: obtaining authentication information corresponding to the data query request, the authentication information including user identifier, project identifier, controller name, action name, request path, and HTTP method; querying the permission configuration table based on the authentication information to see if there is a permission rule matching the data query request, the permission rule including explicit denial rule and allow rule; if there is an explicit denial rule matching the data query request in the permission configuration table, then it is determined that the data query request is unauthorized and the data query request is rejected; if there is one or more allow rules matching the data query request in the permission configuration table, then the maximum number of returned records quota value of the data query request is determined according to the one or more allow rules, the maximum number of returned records quota value is used to limit the upper limit of the amount of data obtained by the client based on the data query request; if there is no permission rule matching the data query request in the permission configuration table, then the data query request is processed according to the default rule.

[0010] Optionally, in the data management method based on a vector database according to the present invention, the process of querying a relational database and a vector database based on the data query request to obtain a candidate primary key set and then returning the result to the relational database to generate a response data list includes: querying the relational database based on the query text in the data query request; performing a similarity search in the vector database based on the query vector corresponding to the query text to obtain a candidate primary key set; returning the result to the relational database based on the candidate primary key set to load the corresponding candidate entity instances to generate a response data list; and truncating the response data list according to the maximum number of returned records quota value so that the maximum number of returned records quota value candidate entity instances in the response data list are returned to the client.

[0011] Optionally, in the data management method based on a vector database according to the present invention, similarity retrieval is performed in the vector database based on the query vector corresponding to the query text, including: obtaining the tenant identifier corresponding to the data query request and a specified tag set and business status, and generating a metadata filtering dictionary based on the tenant identifier, tag set, and business status; obtaining multiple pre-filtered vector records from the vector database based on the metadata filtering dictionary; performing similarity retrieval in the multiple pre-filtered vector records based on the query vector, including: calculating the similarity between the query vector and the embedded vector in each pre-filtered vector record, determining a similarity score based on the similarity, so as to obtain the candidate primary key corresponding to one or more pre-filtered embedded vectors with the highest similarity score and the corresponding similarity score; loading the corresponding candidate entity instance from the relational database based on the candidate primary key set to generate a response data list, including: loading the corresponding candidate entity instance from the relational database based on each candidate primary key; determining the fusion score of the candidate entity instance based on the similarity score, semantic weight, and business sorting key of each candidate entity instance; and merging and sorting each candidate entity instance based on the fusion score of each candidate entity instance to generate a response data list.

[0012] Optionally, in the data management method based on a vector database according to the present invention, if there are one or more allowable rules in the permission configuration table that match the data query request, then determining the maximum number of returned records for the data query request according to the one or more allowable rules includes: if there is one allowable rule in the permission configuration table that matches the data query request, then determining the maximum number of returned records for the data query request according to the maximum number of data records in the allowable rule; if there are multiple allowable rules in the permission configuration table that match the data query request, then determining the allowable rule with the highest priority among the multiple allowable rules, and determining the maximum number of returned records for the data query request according to the maximum number of data records in the allowable rule with the highest priority.

[0013] Optionally, in the data management method based on a vector database according to the present invention, when the data processing request is a data deletion request, the primary key of the entity instance to be deleted is obtained from the data deletion request; the entity instance to be deleted is obtained from the relational database according to the primary key of the entity instance to be deleted; the dependent navigation objects and the dependent navigation objects of the entity instance to be deleted are recursively deleted; the main entity of the entity instance to be deleted is deleted, and the corresponding vector record in the vector database is deleted according to the primary key of the entity instance to be deleted.

[0014] According to one aspect of the present invention, a data management system is provided, comprising: a relational database; a vector database; a server, communicatively connected to the relational database and the vector database, adapted to perform the method described above; and a client, communicatively connected to the server, adapted to send a data processing request carrying a context name and an entity name to the server.

[0015] According to one aspect of the present invention, a computing device is provided, comprising: at least one processor; and a memory storing program instructions, wherein the program instructions are configured to be executed by the at least one processor, the program instructions including instructions for performing the data management method based on a vector database as described above.

[0016] According to one aspect of the present invention, a computer program product is provided, comprising computer program instructions, wherein the computer program instructions, when executed by a processor, implement the method as described above.

[0017] According to one aspect of the present invention, a readable storage medium storing program instructions is provided, which, when read and executed by a computing device, causes the computing device to perform the data management method based on a vector database as described above.

[0018] According to the technical solution of this invention, a data management method based on a vector database is provided. This method receives general CRUD (Create, Read, Update, Delete) requests carrying context names and entity names through a unified controller, thereby supporting generalized processing of massive entities and multiple data contexts and reducing redundant interfaces. For data creation and update requests, while performing relational persistence operations, embedded vectors are generated based on embeddable fields and written to the vector database. When a data query request is received, after performing permission and quota verification, both the relational database and the vector database are queried to obtain a set of candidate primary keys, and a response data list is generated by returning the data to the relational database. Based on this, without sacrificing generality, permission and quota management, relational persistence, vector writing, and table retrieval can be unified for data management, balancing transaction consistency and semantic retrieval capabilities. Furthermore, permission and quota verification improves data security.

[0019] Furthermore, multiple pre-filtered vector records matching the query conditions are obtained from the vector database based on tenant identifiers, tag sets, and business status. Similarity retrieval is then performed based on the query vectors, and the retrieval results are merged and ranked according to the fusion score. This approach maintains high recall in vector retrieval while enabling fine-grained access control based on tenant, tag, and business status, ensuring strict data isolation between different tenants. Simultaneously, the fusion ranking system balances semantic relevance and business weight.

[0020] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0021] To achieve the foregoing and related objectives, certain illustrative aspects are described herein in conjunction with the following description and accompanying drawings. These aspects indicate various ways in which the principles disclosed herein may be practiced, and all aspects and their equivalents are intended to fall within the scope of the claimed subject matter. The foregoing and other objectives, features, and advantages of this disclosure will become more apparent from the following detailed description, taken in conjunction with the accompanying drawings. Throughout this disclosure, the same reference numerals generally refer to the same parts or elements.

[0022] Figure 1 A schematic diagram of a data management system 100 provided according to an embodiment of the present invention is shown; Figure 2 A schematic diagram of a computing device 200 provided according to an embodiment of the present invention is shown; Figure 3 A flowchart illustrating a data management method 300 based on a vector database according to an embodiment of the present invention is shown. Detailed Implementation

[0023] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0024] To address the problems existing in the use of relational databases for CRUD operations in the prior art, this invention provides a data management method based on a vector database. By unifying the general CRUD capabilities of relational data with the semantic retrieval capabilities of vector databases, this method can unify permissions and quotas, relation persistence, vector writing and table lookup for data management without sacrificing versatility, thus balancing transaction consistency and semantic retrieval capabilities.

[0025] The data management method based on a vector database provided in the embodiments of the present invention can be implemented in a data management system. The data management method and data management system based on a vector database according to the embodiments of the present invention are applicable to enterprise-level scenarios requiring structured management and semantic retrieval, such as knowledge management, customer service retrieval, work order services, R&D documents and compliance archives.

[0026] Figure 1 A schematic diagram of a data management system 100 provided according to an embodiment of the present invention is shown.

[0027] like Figure 1 As shown, the data management system 100 may include one or more clients 110, a server 120, a relational database 130, and a vector database 140. The server 120 and client 110 can be connected via network communication, for example, via wired or wireless means. Furthermore, the server 120 is communicatively connected to the relational database 130 and the vector database 140, respectively.

[0028] Client 110 can be a terminal device used by the user, which can be a personal computer such as a desktop computer or laptop, or a mobile terminal such as a mobile phone, tablet computer, multimedia device, or smart wearable device, but is not limited to these. Client 110 can also be an application residing on the terminal device.

[0029] Server 120 is used to provide data management services to client 110. It can be any computing device in the prior art capable of providing data management services to clients. This invention does not limit the specific type of server. For example, server 120 can be a desktop computer, laptop computer, processor chip, mobile phone, tablet computer, etc., but is not limited to these. The server can also be a service program residing in the computing device.

[0030] In embodiments of the present invention, such as Figure 1 As shown, the server-side 120 includes a controller (router), a permission and quota verification module, a CRUD service layer (i.e., a general CRUD service layer), and an embedded processing module. The server-side 120 can communicate with the client 110 through the controller, thereby receiving data processing requests (carrying context names and entity names) from the client.

[0031] In this embodiment of the invention, the data processing request (i.e., the CRUD request) can be any one of the following: data creation request, data deletion request, data update request, and data query request.

[0032] In embodiments of the present invention, a unified controller communicates with the permission and quota verification module, the CRUD service layer, and the embedding processing module, respectively, thereby enabling the invocation of the functions of these modules to process data processing requests from clients. Specifically, the controller can obtain the context name and entity name from the data processing request, locate the corresponding target database context based on the context name, and obtain the corresponding target entity type based on the entity name. When the data processing request is a data creation request or a data update request, the controller can use the CRUD service layer to perform relational persistence operations on the structured fields (JSON data) in the request body of the data processing request based on the target database context and the target entity type, thereby updating the relational database. Furthermore, the embedding processing module can perform text preprocessing on the embeddable fields in the request body of the data processing request and generate corresponding embedding vectors. Then, the CRUD service layer can write the embedding vectors and corresponding metadata information (which may include primary keys, tenant identifiers, tag sets, and business status) into the vector database.

[0033] It should be noted that before processing data processing requests (including data creation requests, data deletion requests, data update requests, and data query requests) through the CRUD service layer, the permissions and quotas of the data processing requests can be verified in advance through the permission and quota verification module. The data processing requests can only be processed after the verification is passed.

[0034] When the data processing request is a data query request (i.e., a data read request), the permission and quota verification module can be used to verify the permission and quota of the data query request in advance. Then, the CRUD service layer can query the relational database and vector database based on the permission and quota verification results to obtain a set of candidate primary keys. Then, the relational database can be retrieved based on the set of candidate primary keys to generate a response data list.

[0035] In embodiments of the present invention, server 120 can be configured to execute a vector database-based data management method 300. The vector database-based data management method 300 of the present invention will be described in detail below. The specific execution strategies for each module (controller, permission and quota verification module, CRUD service layer, and embedded processing module) in server 120 can be found in the description of the vector database-based data management method 300 below.

[0036] In one embodiment, the server 120 of the present invention can be implemented as a computing device, so that the data management method 300 based on vector database of the present invention can be executed in the computing device.

[0037] Figure 2A schematic diagram of a computing device 200 according to an embodiment of the present invention is shown. Figure 2 As shown, in a basic configuration, computing device 200 includes at least one processing unit 202 and system memory 204. According to one aspect, depending on the configuration and type of the computing device, the processing unit 202 may be implemented as a processor. System memory 204 includes, but is not limited to, volatile memory (e.g., random access memory), non-volatile memory (e.g., read-only memory), flash memory, or any combination of such memories. According to one aspect, system memory 204 includes an operating system 205.

[0038] According to one aspect, operating system 205 is, for example, suitable for controlling the operation of computing device 200. Furthermore, examples are practiced in conjunction with graphics libraries, other operating systems, or any other applications, and are not limited to any particular application or system. Figure 2 The basic configuration is illustrated by the components within the dashed lines. According to one aspect, the computing device 200 has additional features or functions. For example, according to one aspect, the computing device 200 includes additional data storage devices (removable and / or non-removable), such as disks, optical discs, or magnetic tapes. This additional storage... Figure 2 The middle part is shown by removable storage device 209 and non-removable storage device 210.

[0039] As stated above, according to one aspect, program module 203 is stored in system memory 204. According to one aspect, program module 203 may include one or more applications. The present invention does not limit the type of application; for example, applications may include: email and contact applications, word processing applications, spreadsheet applications, database applications, slideshow applications, drawing or computer-aided applications, web browser applications, etc.

[0040] In an embodiment of the present invention, program module 203 includes multiple program instructions for executing the data management method 300 based on a vector database of the present invention.

[0041] According to one aspect, examples can be practiced on circuits including discrete electronic components, packaged or integrated electronic chips containing logic gates, circuits utilizing microprocessors, or on a single chip containing electronic components or a microprocessor. For example, it can be practiced via wherein... Figure 2Each or many of the components shown can be implemented as an example by integrating a System-on-a-Chip (SOC) on a single integrated circuit. According to one aspect, such an SOC device may include one or more processing units, graphics units, communication units, system virtualization units, and various application functions, all integrated (or “burned in”) as a single integrated circuit onto a chip substrate. When operating via the SOC, the functions described herein can be operated via dedicated logic integrated on a single integrated circuit (chip) with other components of the computing device 200. Embodiments of the invention can also be implemented using other techniques capable of performing logical operations (e.g., AND, OR, and NOT), including but not limited to mechanical, optical, fluid, and quantum technologies. Additionally, embodiments of the invention can be implemented within a general-purpose computer or in any other circuit or system.

[0042] According to one aspect, computing device 200 may also have one or more input devices 212, such as a keyboard, mouse, pen, voice input device, touch input device, etc. It may also include output devices 214, such as a display, speaker, printer, etc. The foregoing devices are examples and other devices may also be used. Computing device 200 may include one or more communication connections 216 that allow communication with other computing devices 218. Examples of suitable communication connections 216 include, but are not limited to: RF transmitter, receiver and / or transceiver circuitry; Universal Serial Bus (USB), parallel and / or serial ports.

[0043] As used herein, the term computer-readable medium includes computer storage medium. Computer storage medium can include volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information (e.g., computer-readable instructions, data structures, or program modules). System memory 204, removable storage device 209, and non-removable storage device 210 are examples of computer storage media (i.e., memory storage). Computer storage media can include random access memory (RAM), read-only memory (ROM), electrically erasable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital universal disc (DVD) or other optical storage, magnetic tape, magnetic tape, disk storage or other magnetic storage devices, or any other article of manufacture that can be used to store information and is accessible by computing device 200. According to one aspect, any such computer storage medium can be part of computing device 200. Computer storage media does not include carrier waves or other transmitted data signals.

[0044] According to one aspect, a communication medium is implemented by computer-readable instructions, data structures, program modules, or other data in a modulated data signal (e.g., a carrier wave or other transmission mechanism), and includes any information transmission medium. According to one aspect, the term "modulated data signal" describes a signal having one or more sets of characteristics or altered in a manner that encodes information in the signal. By way of example and not limitation, a communication medium includes wired media such as wired networks or direct wired connections, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.

[0045] In an embodiment of the present invention, a computing device 200 is configured to execute a vector database-based data management method 300. The computing device 200 includes one or more processors and one or more readable storage media storing program instructions. When the program instructions are configured to be executed by one or more processors, the computing device executes the vector database-based data management method 300 of the present invention, so that the computing device 200 performs CRUD (Create, Read, Update, Delete) management by executing the vector database-based data management method 300 of the present invention.

[0046] In some embodiments, the computing device that executes the data management method 300 based on a vector database in the present invention can be a server, that is, the data management method 300 based on a vector database can be executed on the server.

[0047] The data management method 300 based on a vector database in the embodiments of the present invention will be described in detail below.

[0048] Figure 3 A flowchart illustrating a data management method 300 based on a vector database according to an embodiment of the present invention is shown. Figure 3 As shown, the data management method 300 based on a vector database includes the following steps 310-340.

[0049] Step 310: Server 120 can receive data processing requests from client 110 carrying context names and entity names through the controller (unified controller). Subsequently, it locates the corresponding target database context based on the context name and obtains the corresponding target entity type based on the entity name. Then, the data processing request can be processed through the CRUD service layer.

[0050] In this embodiment of the invention, a data processing request (i.e., a CRUD request) can be any one of a data creation request, a data deletion request, a data update request, or a data query request. The data processing request carries a context name (i.e., the database context name, contextName) and an entity name (i.e., the entity type name, entityName).

[0051] In some embodiments, client 110 can send a data processing request carrying a context name and entity name to server 120 via a REST interface. Specifically, when sending the data processing request, client 110 can submit the context name and entity name together as path parameters. Server 120 (controller) can parse the context name and entity name from the path segment of the data processing request, thereby supporting generalized processing of multiple contexts and multiple entities.

[0052] In some embodiments, the server-side 120 (controller) can locate the corresponding target database context in a pre-configured set of contexts based on the context name, such as locating the PostgreSQL context based on pgContext. Then, it retrieves the corresponding target entity type from the assembly containing the business entity based on the entity name, such as searching for the target entity type named addressbook under the zhida.Models namespace.

[0053] When the data processing request is a data creation request or a data update request, the server 120 can execute the following steps 320-330.

[0054] Step 320: Through the CRUD service layer, based on the target database context and target entity type, perform relational persistence operations on the structured fields (JSON data) in the request body of the data processing request to update the relational database 130.

[0055] In some embodiments, in step 330, firstly, the controller can deserialize the structured fields (JSON data) in the request body of the data processing request based on the target entity type to obtain an entity instance of the target entity type. During the deserialization process, the structured fields can be converted and assigned values ​​according to the target entity type to obtain an entity instance of the target entity type. Then, the CRUD service layer can perform relation persistence operations on the entity instance based on the target database context.

[0056] Specifically, during the relationship persistence operation on an entity instance, the main entity corresponding to the entity instance can first be attached to the target database context.

[0057] Subsequently, each navigation attribute of the main entity (i.e., all navigation attributes declared by the main entity in the ORM metadata) can be traversed, and each navigation sub-entity corresponding to each navigation attribute (e.g., detail rows, ancillary information, etc.) can be recursively added to the tracking set of the target database context. In some embodiments, navigation attributes include collection-type navigation attributes and single-value navigation attributes. For collection-type navigation attributes, each navigation sub-entity corresponding to the collection-type navigation attribute can be traversed, and each navigation sub-entity corresponding to the collection-type navigation attribute can be recursively added to the tracking set of the target database context. For single-value navigation attributes, the navigation sub-entities corresponding to the single-value navigation attributes can be recursively added to the tracking set of the target database context.

[0058] Furthermore, the ORM framework can be used to write entity instances (mapped to records in the tables) into the corresponding table columns in relational database 130 based on the mapping relationship between entity types and tables in relational database 130, and generate or update the corresponding table row records and the primary key corresponding to the entity instance. The generated primary key can be automatically populated back into the entity instance. The primary key can be, for example, an auto-incrementing ID or a GUID.

[0059] In some embodiments, null value validation can be performed before writing entity instances into relational database 130. Specifically, before using the ORM framework to write entity instances into the corresponding table columns in relational database 130 based on the mapping relationship between entity types and tables in relational database 130, it is possible to iterate and determine whether each navigation attribute corresponding to each navigation sub-entity recursively added to the tracking set of the target database context is allowed to be null. If the navigation attribute is not allowed to be null (including non-nullable value types or those configured as required), it is further determined whether the value of the navigation attribute is null. If the value of the navigation attribute is null, the writing of entity instances into the corresponding table columns in relational database 130 is stopped. Specifically, a parameter exception can be thrown, prompting the caller to complete the necessary fields and retry, in order to prevent illegal data from being written to relational database 130.

[0060] According to the relationship persistence operation process of the present invention, the transactional relationship of structured fields can be stored and decoupled from the subsequent embeddable field vector generation and vector writing process, while maintaining consistency. In addition, the recursive addition mechanism can complete the full graph persistence of the main entity and its navigation sub-entities in a single creation operation, ensuring that the association relationship between entities is correctly saved.

[0061] In addition, performing null value validation before writing to relational database 130 can detect data quality issues in advance and avoid database-level constraint anomalies or semantic incompleteness during subsequent retrieval and vector calculations due to missing fields.

[0062] Step 330: The embedding processing module preprocesses the embeddable fields in the request body of the data processing request and generates corresponding embedding vectors. Subsequently, the embedding vectors and corresponding metadata information can be written to (or updated) the vector database 140 through the CRUD service layer. Here, the embedding vectors and corresponding metadata information are written to the vector database 140 to form a vector record in the vector database 140.

[0063] In this embodiment of the invention, the metadata information in step 330 may include the primary key (the primary key corresponding to the aforementioned entity instance), tenant identifier, tag set, and business status, thereby establishing a correspondence between the embedded vector and metadata information such as the primary key. Furthermore, in some embodiments, the metadata information may also include the vector model identifier and model dimensions.

[0064] It's important to note that "structured fields" refer to fields that can be directly mapped to the 130 columns of a relational database, possessing clearly defined data types and constraints. These include strings, numeric values, boolean values, date / time values, enumeration types, and identifier fields used for foreign key associations. For example, in a "work order" entity, work order number (string), work order title (string), priority (enumeration or numeric), creation time (date / time), status (enumeration), tenant ID (integer or string), and responsible user ID (integer or string) are all structured fields. Similarly, in a "knowledge document" entity, document ID, document name, project, creator, creation time, and business status are all structured fields. Correspondingly, document text, summaries, and tag text can be considered "embeddable fields."

[0065] In some embodiments, embeddable fields may include, for example, a title, a summary, a body, and tags.

[0066] In this embodiment of the invention, before processing data processing requests (including data creation requests, data deletion requests, data update requests, and data query requests) through the CRUD service layer, the data processing requests can be pre-verified using the permission and quota verification module. The data processing requests can then be processed only after the verification is successful.

[0067] In this embodiment of the invention, when the data processing request is a data query request (i.e., a data read request), the server 120 may execute the following steps 340.

[0068] Step 340: The permission and quota verification module can be used to verify the permissions and quotas of the data query request. Then, the CRUD service layer can query the relational database 130 and the vector database 140 based on the permission and quota verification results to obtain the candidate primary key set and return it to the relational database 130 to generate the response data list.

[0069] In this embodiment of the invention, the data query request may include query text. The data query request supports multiple methods such as full data reading, paginated reading, and primary key reading. It also supports including path parameters to load navigation attributes and returns data and totals in the pagination interface.

[0070] In some embodiments, the specific process of verifying permissions and quotas for data query requests in step 340 is as follows: The authentication information corresponding to the data query request can be obtained in advance through the controller. The authentication information includes user ID, project ID, controller name, action name, request path, and HTTP method.

[0071] When performing permission and quota verification on a data query request through the permission and quota verification module, the system can query the permission configuration table based on the authentication information to see if there is a permission rule that matches the data query request. Permission rules include explicit deny rules and allow rules. If an explicit deny rule that matches the data query request exists in the permission configuration table, it is determined that the data query request is unauthorized (permission verification failed), and the data query request is rejected. For example, an error response of "unauthorized" or "access denied" can be returned to client 110.

[0072] If the permission configuration table contains one or more allow rules that match the data query request, indicating that the permission verification is successful, the maximum number of returned records for the data query request can be determined based on these one or more allow rules. This maximum return record quota is used to limit the upper limit of the amount of data that client 110 can obtain based on the data query request. Specifically, if the permission configuration table contains one allow rule that matches the data query request, the maximum return record quota for the data query request can be determined directly based on the maximum number of records in the allow rule. If the permission configuration table contains multiple allow rules that match the data query request, the allow rule with the highest priority among the multiple allow rules is determined, and the maximum return record quota for the data query request is determined based on the maximum number of records in the highest priority allow rule.

[0073] If there is no matching permission rule in the permission configuration table that matches the data query request (neither an explicit deny rule nor a matching allow rule), the data query request will be processed according to the default rule (e.g., the default deny rule). For example, the data query request will be intercepted based on the default deny rule.

[0074] Furthermore, the CRUD service layer can query the relational database 130 and the vector database 140 based on the permission and quota verification results (after the permission verification is passed). Specifically, the relational database 130 can be queried based on the query text in the data query request (using keyword filtering), and a similarity retrieval can be performed in the vector database 140 based on the query vector corresponding to the query text to obtain a set of candidate primary keys. Here, the query text can be converted into the corresponding query vector through the embedding processing module. When performing a similarity retrieval in the vector database 140 based on the query vector corresponding to the query text, the similarity between the query vector and each embedded vector in the vector database 140 can be calculated to obtain one or more candidate primary keys with the highest similarity and the corresponding similarity (similarity score). In some embodiments, any one of inner product, cosine similarity, or Euclidean distance can be used to measure similarity, and a similarity score can be calculated based on the similarity. For example, when using Euclidean distance to calculate similarity, the Euclidean distance can be converted into a monotonically increasing similarity score according to a preset function (e.g., the inverse or the normalized reciprocal). Alternatively, if the calculated similarity is a similarity value, it can be directly used as the similarity score. In some embodiments, to facilitate unified processing of different similarity measurement methods, the similarity score can be normalized in the range of 0 to 1 to obtain a similarity score denoted as sim_i.

[0075] Next, the candidate primary key set can be used to retrieve the corresponding candidate entity instances from the relational database 130 to generate a response data list. The response data list is then truncated based on the maximum number of records to be returned, so that only the candidate entity instances with the maximum number of records to be returned are sent to the client 110. For example, the maximum number of records to be returned can be represented as N, meaning the first N entity instances in the response data list will be sent to the client 110.

[0076] In some embodiments, for data query requests, the "maximum number of records returned per request" field can be pre-configured in the allow rules, and long-term quota indicators such as "maximum number of accesses per user per day" or "maximum total number of records returned per user per day" can also be configured. When determining the maximum number of records returned for a data query request according to the allow rules, the "maximum number of records returned per request" in the allow rules can first be obtained as N_max, and the pageSize or limit value in the query parameters of the data query request can be obtained. The smaller of the two values ​​is taken as the maximum number of records returned for this query. Furthermore, the quota statistics table can be queried or updated to count the cumulative number of accesses and returned records of the current client 110 user under the current project and the current interface. If it is found that the execution of this request will exceed the pre-set long-term quota indicator, the data query request is marked as "exceeding the limit", a quota over-limit error is returned to the client 110, and the actual query is no longer executed. Based on this, rate limiting and protection for high-frequency access users can be achieved.

[0077] Furthermore, in some embodiments, row-level and field-level access control can be implemented for data query requests. Specifically, the access rules can carry constraint information such as tenant scope, department scope, and tag scope, for example, "only allow access to current tenant data," "only allow access to data of this department and its subordinate departments," and "only allow access to data whose tags contain a certain business domain tag." When performing relational database queries or table loads, the corresponding constraints can be converted into WHERE conditions or vector metadata filtering conditions based on the current user's tenant representation, department ID, and tag set, ensuring that the final returned record rows all meet the restrictions of "belonging tenant," "belonging department," and "tag scope," thereby achieving row-level access control based on tenant, department, and tag. In field-level control, visibility and editability can be configured for each sensitive field in the access rules, such as "normal display," "masked display," "read-only," and "invisible." For data query requests, after obtaining entity objects (candidate entity instances) from relational database 130 or by table lookup, fields marked as "invisible" can be removed according to field-level rules, and fields marked as "masked" can be replaced with mask values ​​(e.g., partially anonymized strings). Only the content of fields that are allowed to be viewed is returned. For data update requests, after deserializing the structured fields in the request body to obtain entity instances of the target entity type, before performing relational persistence operations on the entity instances, all fields marked as "read-only" or "invisible" can be removed or reset according to field-level rules, thereby preventing modification of sensitive fields. Based on this, fine-grained permission and quota management for different users and different projects can be achieved.

[0078] In some embodiments, in step 340, when performing similarity retrieval in the vector database 140, the vector recall results can be pre-filtered using tenant, tag, and business status.

[0079] Specifically, when server 120 receives a data query request from client 110, it can obtain the tenant identifier corresponding to the data query request (i.e., the tenant identifier corresponding to the client 110 user), as well as the tag set and business status specified in the data query request (e.g., "not closed," "effective," etc.). Then, it can generate a metadata filtering dictionary based on the tenant identifier, tag set, and business status. Here, the metadata filtering dictionary includes the tenant identifier, tag set, and business status. Furthermore, the metadata filtering dictionary can be used as a query condition to obtain multiple pre-filtered vector records that meet the query conditions from the vector database 140 (after pre-filtering). Afterward, a similarity search (top-k search) can be performed on the query vector among the multiple pre-filtered vector records. Specifically, the similarity between the query vector and the embedded vector in each pre-filtered vector record can be calculated, and a similarity score can be determined based on the similarity to obtain the candidate primary key corresponding to the one or more pre-filtered embedded vectors with the highest similarity score, along with their corresponding similarity scores.

[0080] For each candidate primary key obtained from the vector database 140, the corresponding candidate entity instance can be loaded from the relational database 130 based on the candidate primary key. In some embodiments, during the table lookup phase, the loaded data can be validated again based on the tenant identifier, tag set, and business status to prevent unauthorized results from being returned due to metadata inconsistencies or index delays.

[0081] In addition, for each candidate entity instance loaded from the relational database 130 by returning the candidate primary key from the vector database 140, the fusion score of the candidate entity instance can be determined based on the similarity score, semantic weight, and business sorting key (such as update time or importance level) corresponding to the candidate entity instance. Specifically, the fusion score of the candidate entity instance can be calculated based on "similarity score × semantic weight + business sorting key". Then, the candidate entity instances can be fused and sorted based on their fusion scores to generate a response data list.

[0082] It should be noted that semantic weights can be pre-configured, specifically by tenant, business type, or interface level. Semantic weights are used to adjust the influence of vector similarity on the final fusion and ranking. For example, in a knowledge-based question-answering scenario, a semantic weight of 0.7 can be configured for vector similarity, while in a pure list browsing scenario, a semantic weight of 0.4 can be configured. Business sorting keys can come from structured fields of various entity types in the relational database 130. Typically, fields reflecting business priority or freshness can be selected, such as update time, creation time, importance level of manual annotation, pinning indicator, click popularity, or rating. In one implementation, one or a set of business sorting fields can be pre-configured for each entity type. For example, for a knowledge document entity, "pinning status" and "last update time" can be used as its business sorting keys; for a work order entity, "priority" and "creation time" can be used as its business sorting keys. When loading the candidate entity instance corresponding to the candidate primary key in the relational database 130, the value of the business sorting key can be extracted from these fields, and it can be converted into a business sorting score in the range of 0 to 1 through linear normalization, graded mapping or scoring function.

[0083] Based on this, while maintaining a high recall rate for vector retrieval, it is possible to achieve fine-grained access control based on tenant, tag, and business status, ensuring strict data isolation between different tenants. At the same time, by fusing and sorting the search results, it is possible to take into account both semantic relevance and business weight, and achieve fine-grained filtering and sorting.

[0084] In some embodiments, when the model dimension corresponding to the embedding vector generated based on the embeddable field is inconsistent with the model dimension of the existing index in the vector database 140, parallel writing of dual indexes (old and new indexes) can be adopted, and the data can be recalled and deduplicated simultaneously in the read path. Specifically, in the same data query request, vector retrieval can be initiated simultaneously to the old index and the new index in the vector database 140, and then the two retrieval results are deduplicated and sorted at the primary key level and merged. Specifically, after passing the permission and quota verification, a unified query vector q can be generated based on the query text, and vector retrieval can be initiated to the old index (e.g., Index_v1, corresponding to the old model dimension) and the new index (e.g., Index_v2, corresponding to the new model dimension) based on the same top-k parameters. Each of the two retrievals returns a set of candidate records, and each candidate record contains a candidate primary key, a similarity score, and a source index tag. Furthermore, a candidate dictionary can be created using candidate primary keys as keys. The index results returned by the two indexes are traversed. When it is determined that any candidate primary key appears only in one of the index results, the index result is directly added to the candidate dictionary. When any candidate primary key appears in both the old and new index results, deduplication and optimization can be performed according to a preset strategy. For example, the index result returned by the new index can be retained first, or a new similarity score can be obtained by weighting the similarity scores between the old and new indexes according to a preset semantic weight, and this new similarity score can be used as the unique candidate record for that candidate primary key, thereby completing the deduplication based on the candidate primary key.

[0085] After deduplication, a set of candidate records from the merged old and new indexes is obtained. Then, the fusion score for each candidate record in the set is calculated according to the aforementioned fusion ranking rules (similarity score × semantic weight + business ranking key). Specifically, for candidate records from a single index, the normalized similarity value returned by that index can be directly used as the similarity score. For candidate records that appear in both the old and new indexes, a weighting method of "new index score × model upgrade semantic weight + old index score × compensation semantic weight" is used to give the new model's retrieval results higher priority in ranking. Afterward, based on the similarity score, the fusion score can be calculated in conjunction with the business ranking key (e.g., update time, importance level), and the records are ranked from highest to lowest fusion score within the same candidate record set. Through this method, even when maintaining both old and new indexes simultaneously during the model upgrade transition phase, the read path presents a single, stable search interface to the caller, prioritizing the use of the new model's retrieval capabilities.

[0086] In some embodiments, in response to a data update request, the main entity corresponding to the entity instance can be marked as modified, and each navigation attribute (including collection-type navigation attributes and single-value navigation attributes) of the main entity can be traversed. Each navigation attribute can be marked as modified one by one and then saved uniformly. At the same time, the corresponding embedding vectors of the affected fields can be regenerated and idempotently updated in the vector database 140.

[0087] In some embodiments, the text preprocessing in step 330 may include operations such as control character cleaning, whitespace normalization, full-width and half-width character unification, optional word segmentation and stop word filtering, optional simplified / traditional conversion and case normalization.

[0088] In some embodiments, the metadata information in step 330 can be obtained in the following ways: First, since the ORM framework can automatically backfill the generated primary key into the entity instance, the primary key (primary key value) can be read from the entity instance through reflection or by agreeing on field names (e.g., Id, xxxId) as the unique identifier of the vector record. Second, the tenant identifier can be obtained from the authentication context of the data processing request. For example, in a multi-tenant scenario, the token obtained after a user logs in contains declaration fields such as tenant_id. Therefore, the tenant identifier can be parsed from the token and written into the vector record as tenant identifier metadata for subsequent retrieval and filtering based on the tenant identifier. Additionally, a tag set can be obtained based on the structured fields and derived tags of entity instances. It's important to note that, on one hand, entity instances typically contain structured fields such as title, category, business type, business status, and domain identifier. By cleaning, normalizing, and splitting these structured fields, the resulting keyword set is used as tags. On the other hand, a set of system tags, such as "work order," "knowledge base," and "customer information," can be added based on the business table to which the entity instance belongs, controller name, interface path, or manual configuration. These tags ultimately form a tag set, which is then written as tag metadata into the vector record. Furthermore, vector model identifiers and model dimension information can come from a unified configuration of the vector model. Specifically, a vector model identifier (e.g., model name or version number) and corresponding model dimensions (e.g., 512-dimensional, 768-dimensional, or 1024-dimensional) can be pre-configured for each tenant or business type, allowing the vector model identifier and model dimensions to be obtained from the configuration information.

[0089] In some embodiments, when the data processing request is a data deletion request, the primary key of the entity instance to be deleted can be obtained from the data deletion request. Based on the primary key of the entity instance to be deleted, the entity instance to be deleted is retrieved from the relational database 130. Then, the dependent navigation objects (child entities) and dependent navigation objects (parent entities) of the entity instance to be deleted are recursively deleted. Afterward, the main entity of the entity instance to be deleted is deleted, and the corresponding vector record in the vector database 140 is deleted based on the primary key of the entity instance to be deleted. In some embodiments, dependent navigation objects and dependent navigation objects can be distinguished based on the navigation metadata and foreign key information provided by the ORM framework. Specifically, when deleting the main entity, dependent navigation objects (child entities) can be recursively traversed and marked as "deleted" to ensure that no isolated records are left behind. For dependent navigation objects (parent entities), whether to cascade deletion or only delete the current entity can be selected according to business rules to avoid unintentionally deleting multiple shared parent entities. Based on this, a safe and controllable recursive deletion strategy can be constructed.

[0090] According to the data management method 300 based on a vector database of the present invention, a unified controller receives general CRUD requests carrying context names and entity names, thereby supporting generalized processing of massive entities and multiple data contexts and reducing redundant interfaces. For data creation and update requests, while performing relation persistence operations, embedded vectors are generated based on embeddable fields and written to the vector database. When a data query request is received, after performing permission and quota verification, the relational database and vector database are queried to obtain a set of candidate primary keys, and the result is retrieved from the relational database to generate a response data list. Based on this, without sacrificing generality, permission and quota, relation persistence, vector writing, and table retrieval can be unified for data management, balancing transaction consistency and semantic retrieval capabilities. Furthermore, permission and quota verification improves data security.

[0091] Furthermore, multiple pre-filtered vector records matching the query conditions are obtained from the vector database based on tenant identifiers, tag sets, and business status. Similarity retrieval is then performed based on the query vectors, and the retrieval results are merged and ranked according to the fusion score. This approach maintains high recall in vector retrieval while enabling fine-grained access control based on tenant, tag, and business status, ensuring strict data isolation between different tenants. Simultaneously, the fusion ranking system balances semantic relevance and business weight.

[0092] The various techniques described herein can be implemented in combination with hardware or software, or a combination thereof. Thus, the methods and apparatus of the present invention, or certain aspects or portions thereof, can take the form of program code (i.e., instructions) embedded in a tangible medium, such as a removable hard disk, USB flash drive, floppy disk, CD-ROM, or any other machine-readable storage medium, wherein when the program is loaded into and executed by a machine such as a computer, the machine becomes an apparatus for practicing the present invention.

[0093] When the program code is executed on a programmable computer, the mobile terminal generally includes a processor, a processor-readable storage medium (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. The memory is configured to store program code; the processor is configured to execute the vector database-based data management method of the present invention according to instructions in the program code stored in the memory.

[0094] By way of example, and not limitation, readable media include readable storage media and communication media. Readable storage media stores information such as computer-readable instructions, data structures, program modules, or other data. Communication media generally embodies computer-readable instructions, data structures, program modules, or other data in the form of modulated data signals such as carrier waves or other transmission mechanisms, and includes any information delivery medium. Any combination of the above is also included within the scope of readable media.

[0095] In the specification provided herein, the algorithms and displays are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used with the examples of this invention. The required structure for constructing such systems is apparent from the above description. Furthermore, this invention is not directed to any particular programming language. It should be understood that the contents of the invention described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of the invention.

[0096] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0097] Similarly, it should be understood that, in order to streamline this disclosure and aid in understanding one or more of the various aspects of the invention, in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof.

[0098] Those skilled in the art will understand that modules, units, or components of the devices disclosed in the examples herein can be arranged in the devices described in this embodiment, or alternatively, can be located in one or more devices different from the devices in this example. The modules in the foregoing examples can be combined into a single module or, in addition, can be divided into multiple sub-modules.

[0099] Unless otherwise specified, the use of ordinal numbers such as “first,” “second,” “third,” etc., to describe ordinary objects merely indicates different instances of similar objects and is not intended to imply that the objects being described must have a given order in time, space, ordering, or any other manner.

Claims

1. A data management method based on a vector database, executed on the server side, the method comprising: Receive a data processing request from the client carrying a context name and an entity name; locate the corresponding target database context based on the context name; and obtain the corresponding target entity type based on the entity name. When the data processing request is a data creation request or a data update request, based on the target database context and the target entity type, a relation persistence operation is performed on the structured fields in the request body of the data processing request to update the relational database. The embeddable fields in the request body of the data processing request are preprocessed with text and corresponding embedding vectors are generated. The embedding vectors and corresponding metadata information are written into the vector database. The metadata information includes primary key, tenant identifier, tag set and business status. When the data processing request is a data query request, the data query request is subject to permission and quota verification. Based on the permission and quota verification results, the relational database and vector database are queried to obtain a set of candidate primary keys and the data is retrieved from the relational database to generate a response data list.

2. The method as described in claim 1, wherein, Based on the target database context and the target entity type, perform relational persistence operations on the structured fields in the request body of the data processing request, including: Based on the target entity type, the structured fields in the request body of the data processing request are deserialized to obtain an entity instance of the target entity type; Based on the target database context, perform relationship persistence operations on the entity instance.

3. The method as described in claim 2, wherein, Based on the target database context, perform relation persistence operations on the entity instance, including: Attach the main entity corresponding to the entity instance to the target database context; Iterate through each navigation attribute of the main entity and recursively add each navigation sub-entity corresponding to each navigation attribute to the tracking set of the target database context; Using an ORM framework, based on the mapping relationship between entity types and tables in a relational database, the entity instance is written into the corresponding table column in the relational database, and the corresponding table row record and the primary key corresponding to the entity instance are generated or updated.

4. The method of claim 3, wherein, Before using the ORM framework to write the entity instance into the corresponding table column in the relational database based on the mapping relationship between entity type and tables in the relational database, the process includes: Iterate through and determine whether each navigation attribute corresponding to each navigation sub-entity recursively added to the tracking set of the target database context is allowed to be null; If a navigation attribute is not allowed to be empty, then determine whether the value of the navigation attribute is empty; If the value of the navigation attribute is empty, then the writing of the entity instance into the corresponding table column in the relational database will be stopped.

5. The method according to any one of claims 1-4, wherein, The data query request is subject to permission and quota verification, including: Obtain the authentication information corresponding to the data query request. The authentication information includes user identifier, project identifier, controller name, action name, request path, and HTTP method. The authentication information is used to query whether there is a permission rule in the permission configuration table that matches the data query request. The permission rule includes explicit deny rules and allow rules. If an explicit denial rule matching the data query request exists in the permission configuration table, then the data query request is determined to be unauthorized and is denied. If there is one or more permission rules in the permission configuration table that match the data query request, then the maximum number of returned records for the data query request is determined according to the one or more permission rules. The maximum number of returned records quota is used to limit the upper limit of the amount of data obtained by the client based on the data query request. If there is no permission rule matching the data query request in the permission configuration table, the data query request will be processed according to the default rule.

6. The method of claim 5, wherein, Based on the permission and quota verification results, the relational database and vector database are queried according to the data query request to obtain a candidate primary key set and then the data is retrieved from the relational database to generate a response data list, including: The query text in the data query request is used to query a relational database, and the query vector corresponding to the query text is used to perform a similarity search in the vector database to obtain a set of candidate primary keys. The candidate primary key set is used to retrieve the corresponding candidate entity instances from the relational database to generate a response data list. The response data list is then truncated according to the maximum number of returned records quota value so that the maximum number of returned records quota value of the candidate entity instances in the response data list is returned to the client.

7. The method of claim 6, wherein, Based on the query vector corresponding to the query text, a similarity search is performed in the vector database, including: Obtain the tenant identifier, specified tag set, and business status corresponding to the data query request, and generate a metadata filtering dictionary based on the tenant identifier, tag set, and business status; Based on the metadata filtering dictionary, multiple pre-filtered vector records are obtained from the vector database; Based on the query vector, similarity retrieval is performed on the multiple pre-screened vector records, including: calculating the similarity between the query vector and the embedded vector in each pre-screened vector record, determining the similarity score based on the similarity, so as to obtain the candidate primary key and the corresponding similarity score of one or more pre-screened embedded vectors with the highest similarity score. Based on the candidate primary key set, the corresponding candidate entity instances are retrieved from the relational database to generate a response data list, including: Based on each candidate primary key, retrieve the corresponding candidate entity instance from the relational database; The fusion score of each candidate entity instance is determined based on its similarity score, semantic weight, and business sorting key. The candidate entity instances are merged and sorted according to their fusion scores to generate a response data list.

8. The method of claim 5, wherein, If the permission configuration table contains one or more permission rules that match the data query request, then the maximum number of returned records for the data query request is determined based on the one or more permission rules, including: If there is an allow rule in the permission configuration table that matches the data query request, then the maximum number of returned records for the data query request is determined based on the maximum number of data records in the allow rule. If the permission configuration table contains multiple permission rules that match the data query request, then the permission rule with the highest priority among the multiple permission rules is determined, and the maximum number of returned records for the data query request is determined based on the largest data record number segment in the permission rule with the highest priority.

9. The method according to any one of claims 1-8, wherein, When the data processing request is a data deletion request, the primary key of the entity instance to be deleted is obtained from the data deletion request; Retrieve the entity instance to be deleted from the relational database based on the primary key of the entity instance to be deleted; Recursively delete the dependent navigation objects and the dependent navigation objects of the entity instance to be deleted; Delete the main entity of the entity instance to be deleted, and delete the corresponding vector record in the vector database based on the primary key of the entity instance to be deleted.

10. A data management system, comprising: Relational database; Vector database; The server-side is communicatively connected to the relational database and vector database, and is adapted to execute the method as described in any one of claims 1-9; The client, which communicates with the server, is adapted to send a data processing request carrying a context name and an entity name to the server.

11. A computing device, comprising: At least one processor; and A memory storing program instructions, wherein the program instructions are configured to be processed by the at least one processor, the program instructions including instructions for processing the method as described in any one of claims 1-9.

12. A computer program product comprising computer program instructions, wherein, When the computer program instructions are executed by the processor, they implement the method as described in any one of claims 1-9.

Images