Data query method and device, equipment and medium

Abstract

The invention provides a data query method and device, equipment and a medium, and relates to the technical field of computer software, in particular to the technical field of databases. The method comprises the steps that a logic query request for a logic wide table is received, the logic wide table is constructed based on multiple physical tables, and multiple groups of dependency relationships exist among the multiple physical tables; analyzing the logic query request to determine a to-be-queried target table in a plurality of physical tables; sorting the plurality of groups of dependencies to obtain a global dependency sequence and a reference table in the plurality of physical tables; on the basis of the topological structure, determining a necessary dependence path from the reference table to the target table; respectively converting at least one necessary dependency relationship included in the necessary dependency path into physical table connection relationships, and sequentially combining the physical table connection relationships according to the sequence of the at least one necessary dependency relationship in the global dependency relationship sequence to obtain a physical query statement; and performing data query by utilizing the physical query statement.

Description

Technical Field

[0001] This disclosure relates to the field of computer software technology, and more particularly to the field of database technology, specifically to a data query method, a data query device, an electronic device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] With the rapid development of internet and big data technologies, data warehouses have become a crucial infrastructure for enterprises to store, manage, and analyze data. In existing data processing systems, various upper-layer business applications typically need to interact with the underlying data storage system to obtain data. Generally, applications use common database connection protocols to establish connections with the database and construct query statements based on specific business needs. They then directly retrieve, join, and perform calculations on the physical tables in the underlying database to obtain the required dataset to support subsequent business logic or presentation requirements.

[0003] The methods described in this section are not necessarily methods that had been previously conceived or adopted. Unless otherwise specified, no method described in this section should be assumed to be prior art simply because it is included in this section. Similarly, unless otherwise specified, the issues mentioned in this section should not be considered to be accepted in any prior art. Summary of the Invention

[0004] This disclosure provides a data query method, a data query device, an electronic device, a computer-readable storage medium, and a computer program product.

[0005] According to one aspect of this disclosure, a data query method is provided, comprising: receiving a logical query request for a logical wide table, the logical wide table being constructed based on multiple physical tables, the multiple physical tables having multiple sets of dependencies; parsing the logical query request to determine the target table to be queried among the multiple physical tables; sorting the multiple sets of dependencies based on a topology structure to obtain a global dependency sequence and a base table among the multiple physical tables; determining necessary dependency paths from the base table to the target table based on the topology structure; converting at least one necessary dependency included in the necessary dependency path into physical table join relationships, and sequentially combining physical table join relationships according to the order of at least one necessary dependency in the global dependency sequence to obtain a physical query statement; and performing a data query using the physical query statement.

[0006] According to another aspect of this disclosure, a data query apparatus is provided, comprising: a receiving unit configured to receive a logical query request for a logical wide table, the logical wide table being constructed based on multiple physical tables, the multiple physical tables having multiple sets of dependencies; a parsing unit configured to parse the logical query request to determine a target table to be queried among the multiple physical tables; a sorting unit configured to sort the multiple sets of dependencies based on a topology structure to obtain a global dependency sequence and a base table among the multiple physical tables; a determining unit configured to determine necessary dependency paths connecting the base table to the target table based on the topology structure; a combining unit configured to convert at least one necessary dependency included in the necessary dependency path into physical table joins, and sequentially combine the physical table joins according to the order of at least one necessary dependency in the global dependency sequence to obtain a physical query statement; and a querying unit configured to perform a data query using the physical query statement.

[0007] According to another aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the methods described above.

[0008] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause a computer to perform the above-described method.

[0009] According to another aspect of this disclosure, a computer program product is provided, including a computer program, wherein the computer program implements the above-described method when executed by a processor.

[0010] According to one or more embodiments of this disclosure, by selecting necessary dependencies based on necessary dependency paths, this disclosure can avoid querying redundant tables during data queries, reducing resource consumption overhead and improving query efficiency. Furthermore, by sorting the dependencies and using the obtained global dependency sequence to define the connection order between physical tables on the necessary dependency paths, it ensures the accuracy of the business logic during the data query process and improves the accuracy of the data query results.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0012] The accompanying drawings exemplify embodiments and form part of the specification, serving together with the textual description to explain exemplary implementations of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of the claims. Throughout the drawings, the same reference numerals refer to similar but not necessarily identical elements.

[0013] Figure 1A A schematic diagram of an exemplary system in which the various methods described herein may be implemented according to embodiments of the present disclosure is shown; Figure 1B A schematic diagram of the logical architecture of a data query system according to an embodiment of the present disclosure is shown; Figure 2 A flowchart of a data query method according to an embodiment of the present disclosure is shown; Figure 3 A schematic diagram of a data query method according to an embodiment of the present disclosure is shown; Figure 4 A flowchart illustrating the sorting of multiple sets of dependencies based on a topology structure according to an embodiment of the present disclosure is shown. Figure 5 A flowchart illustrating a topological sorting of multiple physical tables based on a topology according to an embodiment of the present disclosure is shown. Figure 6 A flowchart illustrating the determination of necessary dependency paths from a base table to a target table based on topology, according to an embodiment of the present disclosure, is shown. Figure 7 A flowchart of a data query method according to an embodiment of the present disclosure is shown; Figure 8 A flowchart illustrating the conversion of necessary dependencies into physical table joins according to an embodiment of the present disclosure, and the subsequent combination to obtain a physical query statement; Figure 9 A structural block diagram of a data query apparatus according to an embodiment of the present disclosure is shown; and Figure 10 A structural block diagram of an exemplary electronic device that can be used to implement embodiments of the present disclosure is shown. Detailed Implementation

[0014] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0015] In this disclosure, unless otherwise stated, the use of terms such as "first," "second," etc., to describe various elements is not intended to limit the positional, temporal, or importance relationships of these elements; such terms are merely used to distinguish one element from another. In some examples, the first element and the second element may refer to the same instance of that element, while in other cases, based on the context, they may refer to different instances.

[0016] The terminology used in the description of the various examples in this disclosure is for the purpose of describing particular examples only and is not intended to be limiting. Unless the context explicitly indicates otherwise, an element may be one or more unless the number of elements is specifically limited. Furthermore, the term "and / or" as used in this disclosure covers any one of the listed items and all possible combinations thereof.

[0017] In related technologies, various application systems typically perform data modeling and querying directly on the underlying physical database. As business scenarios become increasingly complex, different application platforms often independently maintain their own data access logic and metric definitions. This decentralized modeling approach leads to a high degree of coupling between the data model and physical storage. When facing cross-platform or cross-topic data analysis needs, problems such as redundant modeling, inconsistent data definitions, and high system maintenance costs easily arise. There is a lack of a unified processing mechanism that can manage data models and efficiently support multi-platform data access.

[0018] To address the aforementioned issues, this disclosure constructs a mapping system between logical wide tables and physical tables, achieving unified data access and model management. This allows upper-layer business logic to perform queries based on the logical layer, thereby shielding the complexity of the underlying physical storage. Furthermore, by selecting necessary dependencies based on essential dependency paths, this disclosure avoids querying redundant tables during data queries, reducing resource consumption and improving query efficiency. Moreover, by sorting dependencies and utilizing the resulting global dependency sequence to define the connection order between physical tables on essential dependency paths, the accuracy of business logic during data querying is ensured, improving the accuracy of data query results.

[0019] Before introducing the method embodiments of this disclosure, the relevant terms will be explained.

[0020] A physical data warehouse is a system used to store enterprise-level business data, which is typically supported by one or more database instances.

[0021] A database is a repository for organizing, storing, and managing data according to a data structure, including but not limited to relational databases (such as MySQL, Oracle, and PostgreSQL), distributed databases (such as Hive and Doris), or non-relational databases (NoSQL, such as document-oriented database MongoDB and column-oriented database HBase).

[0022] A logical wide table is a virtual data view oriented towards a business perspective. It does not actually store data, but rather shields the complex relationships of the underlying physical tables through metadata definitions.

[0023] A physical table refers to a data object that exists in the aforementioned database and can be directly referenced by a physical query statement. It includes not only entity tables and views in relational databases, but also collections or other equivalent data containers in non-relational databases, and can also include virtual table structures defined by custom SQL.

[0024] A data model refers to a set of configuration information used to define the mapping relationship between a logical wide table and multiple physical tables, as well as the dependencies between multiple physical tables. Correspondingly, a logical query request refers to a query instruction initiated by a client or upper-layer application against the logical wide table. It typically contains the logical fields required by the business logic, without needing to know which physical tables these fields are specifically distributed in.

[0025] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0026] Figure 1A A schematic diagram of an exemplary system 100 in which the various methods and apparatus described herein can be implemented according to embodiments of this disclosure is shown. Reference Figure 1A The system 100 includes one or more client devices 101, 102, 103, 104, 105 and 106, a server 120, and one or more communication networks 110 coupling the one or more client devices to the server 120. The client devices 101, 102, 103, 104, 105 and 106 can be configured to execute one or more applications.

[0027] In embodiments of this disclosure, server 120 may run one or more services or software applications that enable the execution of the methods of this disclosure.

[0028] In some embodiments, server 120 may also provide other services or software applications, which may include non-virtual and virtual environments. In some embodiments, these services may be provided as web-based services or cloud services, such as to users of client devices 101, 102, 103, 104, 105 and / or 106 under a Software as a Service (SaaS) model.

[0029] exist Figure 1A In the configuration shown, server 120 may include one or more components that implement the functions performed by server 120. These components may include software components, hardware components, or combinations thereof that can be executed by one or more processors. Users operating client devices 101, 102, 103, 104, 105, and / or 106 can sequentially interact with server 120 using one or more client applications to utilize the services provided by these components. It should be understood that various different system configurations are possible and may differ from system 100. Therefore, Figure 1A This is an example of a system used to implement the various methods described herein, and is not intended to be limiting.

[0030] Users can use client devices 101, 102, 103, 104, 105, and / or 106 for human-computer interaction. The client devices provide interfaces that enable users to interact with them. The client devices can also output information to the user through these interfaces. Although... Figure 1A Only six client devices are described, but those skilled in the art will understand that this disclosure can support any number of client devices.

[0031] Client devices 101, 102, 103, 104, 105, and / or 106 may include various types of computer devices, such as portable handheld devices, general-purpose computers (such as personal computers and laptops), workstation computers, wearable devices, smart screen devices, self-service terminal devices, service robots, gaming systems, thin clients, various messaging devices, sensors, or other sensing devices. These computer devices can run various types and versions of software applications and operating systems, such as Microsoft Windows, Apple iOS, UNIX-like operating systems, Linux or Linux-like operating systems (such as Google Chrome OS); or include various mobile operating systems, such as Microsoft Windows Mobile OS, iOS, Windows Phone, and Android. Portable handheld devices may include cellular phones, smartphones, tablets, personal digital assistants (PDAs), etc. Wearable devices may include head-mounted displays (such as smart glasses) and other devices. Gaming systems may include various handheld gaming devices, internet-enabled gaming devices, etc. Client devices are capable of executing various applications, such as various internet-related applications, communication applications (such as email applications), short message service (SMS) applications, and can use various communication protocols.

[0032] Network 110 can be any type of network well known to those skilled in the art, and can support data communication using any of a variety of available protocols (including but not limited to TCP / IP, SNA, IPX, etc.). By way of example only, one or more networks 110 can be a local area network (LAN), an Ethernet-based network, a token ring network, a wide area network (WAN), the Internet, a virtual network, a virtual private network (VPN), an intranet, an extranet, a blockchain network, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., Bluetooth, WIFI), and / or any combination of these and / or other networks.

[0033] Server 120 may include one or more general-purpose computers, special-purpose server computers (e.g., PC (personal computer) servers, UNIX servers, mid-range servers), blade servers, mainframe computers, server clusters, or any other suitable arrangement and / or combination. Server 120 may include one or more virtual machines running a virtual operating system, or other computing architectures involving virtualization (e.g., one or more flexible pools of logical storage devices that can be virtualized to maintain virtual storage devices for servers). In various embodiments, server 120 may run one or more services or software applications that provide the functionality described below.

[0034] The computing unit in server 120 can run one or more operating systems, including any of the aforementioned operating systems and any commercially available server operating system. Server 120 can also run any of a variety of additional server applications and / or middleware applications, including HTTP servers, FTP servers, CGI servers, JAVA servers, database servers, etc.

[0035] In some implementations, server 120 may include one or more applications to analyze and merge data feeds and / or event updates received from users of client devices 101, 102, 103, 104, 105 and / or 106. Server 120 may also include one or more applications to display data feeds and / or real-time events via one or more display devices of client devices 101, 102, 103, 104, 105 and / or 106.

[0036] In some implementations, server 120 can be a server for a distributed system or a server integrated with blockchain. Server 120 can also be a cloud server, or an intelligent cloud computing server or intelligent cloud host with artificial intelligence technology. A cloud server is a host product in the cloud computing service system, designed to address the shortcomings of traditional physical hosts and Virtual Private Server (VPS) services, such as high management difficulty and weak business scalability.

[0037] System 100 may also include one or more databases 130. In some embodiments, these databases may be used to store data and other information. For example, one or more of the databases 130 may be used to store information such as audio files and video files. Databases 130 may reside in various locations. For example, a database used by server 120 may be local to server 120, or it may be located away from server 120 and may communicate with server 120 via a network-based or dedicated connection. Databases 130 may be of different types. In some embodiments, the database used by server 120 may be, for example, a relational database. One or more of these databases may store, update, and retrieve data from and from the databases in response to commands.

[0038] In some embodiments, one or more of the databases 130 may also be used by an application to store application data. The databases used by the application may be of different types, such as key-value stores, object stores, or regular stores supported by a file system.

[0039] Figure 1AThe system 100 can be configured and operated in various ways to enable the application of the various methods and apparatus described in this disclosure.

[0040] Figure 1B This is a schematic diagram illustrating the logical architecture of a data query system according to an embodiment of the present disclosure. The data query system 140 is... Figure 1A The functions of server 120, database 130 and client devices 101-106 are detailed and logically layered.

[0041] like Figure 1B As shown, the data query system 140 may include an application layer 150, a server 160 (including a unified access interface 162 and a virtual data warehouse service layer 164), and an underlying data storage system 170.

[0042] Application layer 150 is used to send logical query request 152 to server 160, and it can run in Figure 1A On client devices 101-106.

[0043] The unified access interface 162 is deployed on server 160 to receive logical query requests 152 initiated by application layer 150 and provides support for standard database connection protocols, such as Java Database Connectivity (JDBC). Server 160 can correspond to... Figure 1A Server 120 in the middle.

[0044] The virtual data warehouse service layer 164 is deployed on server 160. As the core processing engine of this disclosure, the virtual data warehouse service layer 164 may include the data processing device 900, which will be described below, and may also be used to execute the data processing methods 200 and 700, which will be described below, and their various steps, including logical query request parsing, dependency sorting, determination of necessary dependency paths, and generation of physical query statements, etc., ultimately obtaining physical query statement 166.

[0045] The underlying data storage system 170, namely the physical data warehouse layer, corresponds to... Figure 1A Database 130 is used to store actual physical table data and execute physical query statements 166 generated by the data query device.

[0046] like Figure 1BAs shown, the underlying data storage system 170 can consist of heterogeneous database instances, including but not limited to relational databases (e.g., MySQL 172), distributed analytical databases (e.g., Doris 174), or non-relational databases (e.g., MongoDB 176). The virtual data warehouse service layer 164 can generate physical query statements 166 adapted to the syntax of the specific database instance where the target table resides (e.g., SQL dialect adapted to MySQL, or aggregate pipeline commands adapted to MongoDB). In this way, the application layer 150 does not need to care about the specific type of database where the data is stored, thus decoupling the logical modeling of the application layer from the details of the underlying physical storage.

[0047] According to one aspect of this disclosure, a data query method is provided. For example... Figure 2 As shown, the method 200 includes: step S201, receiving a logical query request for a logical wide table, the logical wide table being constructed based on multiple physical tables, with multiple sets of dependencies between the multiple physical tables; step S202, parsing the logical query request to determine the target table to be queried among the multiple physical tables; step S203, sorting the multiple sets of dependencies based on the topology structure formed by the multiple sets of dependencies to obtain a global dependency sequence and a base table among the multiple physical tables; step S204, determining the necessary dependency paths from the base table to the target table based on the topology structure; step S205, converting at least one necessary dependency included in the necessary dependency path into physical table join relationships, and sequentially combining physical table join relationships according to the order of at least one necessary dependency in the global dependency sequence to obtain a physical query statement; and step S206, performing a data query using the physical query statement.

[0048] Therefore, by selecting necessary dependencies based on necessary dependency paths, this disclosure avoids querying redundant tables during data queries, reducing resource consumption and improving query efficiency. Furthermore, by sorting dependencies and using the resulting global dependency sequence to define the connection order between physical tables on necessary dependency paths, the accuracy of business logic during data querying is ensured, thus improving the accuracy of data query results.

[0049] In some embodiments, dependencies refer to the association constraints or references between physical tables in a data model, such as primary key-foreign key associations or entity relationships in an ER diagram. It should be noted that the method of obtaining these dependencies is not limited in this disclosure. In some embodiments, dependencies can be predefined, such as static model configurations in a storage metadata management system. In other embodiments, dependencies can be dynamically obtained, for example, relationships constructed in real time by the system upon receiving a query request by reading metadata from the underlying database, analyzing historical query logs, or through other means.

[0050] In some embodiments, topology refers to the overall architecture constructed based on multiple sets of dependencies between multiple physical tables, used to characterize the dependency direction or hierarchical order between physical tables, reflecting the logical order that physical tables need to follow when connecting data.

[0051] A baseline table is a physical table that serves as the starting point for a search when constructing a query path. In some embodiments, the baseline table can be a physical table with an in-degree of zero in the topology (i.e., a table that does not depend on any other tables). In other embodiments, the baseline table can also be a physical table dynamically specified based on the query context, such as a core fact table in the business logic, a starting join table explicitly specified by the user, or any other physical table that can be connected to the target table through dependencies.

[0052] In some embodiments, in step S201, receiving a logical query request can be achieved through the Java Database Connectivity Protocol, a unified API gateway, or the query interface of a business intelligence tool. The logical query request can be in standard SQL form or a JSON object in a specific format, and it needs to point to a specific logical wide table.

[0053] In some embodiments, the target table can be a physical table containing the physical fields corresponding to the target logical fields to be queried. In step S202, parsing the logical query request can be implemented using Abstract Syntax Tree (AST) parsing technology. Specifically, the logical fields involved in the logical query request can be identified, and the target table carrying these physical fields can be determined based on pre-stored mapping relationships (e.g., mappings from logical fields to physical fields in each physical table).

[0054] In some embodiments, in step S203, the global dependency sequence refers to an ordered set obtained by sorting the dependencies between all physical tables. By sorting the dependencies, it can be ensured that the table being depended upon (or the preceding table of the relation) always appears before the table that depends on it (or the following table of the relation) in the sequence, while also ensuring that the order of join operations conforms to the logical requirements of data query.

[0055] In some embodiments, in step S204, a necessary dependency path refers to the set of paths in the topology that start from the base table and connect to any target table. Each path may consist of one or more dependencies, which constitute the necessary link connecting the base table and the target table (which may include necessary intermediate tables). All necessary dependency paths can be determined by graph traversal and pruning, thereby retaining paths leading to the target table and eliminating paths that do not lead to any target table.

[0056] In some embodiments, in step S205, physical table joins refer to logical join definitions generated based on static necessary dependencies, used to indicate the merging of different physical tables in the current query. Physical table joins describe which tables need to be joined in this query, and the direction of the join. Accordingly, assembling physical table joins sequentially means assembling these discrete join definitions into an ordered logical chain. Specifically, the order in which each physical table join takes effect can be determined based on the global dependency sequence (e.g., first execute the join between table A and table B, producing an intermediate result, and then execute the join with table C based on this intermediate result), thereby constructing a complete and logically correct physical query statement.

[0057] In one exemplary embodiment, if the target table is located in a document-oriented database (NoSQL), the physical table join relationship can be implemented as a structured data object, such as a lookup phase definition in an aggregation pipeline. Correspondingly, the physical query statement can be implemented as an aggregation pipeline command containing multiple ordered phase definitions.

[0058] In some embodiments, step S206, performing data query using a physical query statement may include: sending the generated physical query statement to the underlying physical data warehouse for execution via a database driver, and encapsulating the returned result set into a format that conforms to the definition of a logical wide table and returning it to the requester.

[0059] The data query method of this disclosure will be described below with reference to an exemplary embodiment. For example... Figure 3 As shown, assuming the data model contains six physical tables from A to F, multiple dependency relationships (310) show that tables B, D, and E all depend on table A, table C depends on table B, and table F depends on table D. Table A is the base table, while tables E and C are the target tables determined after parsing the logical query request.

[0060] First, a full sort is performed on the topology 320 based on multiple sets of dependencies to obtain a global dependency sequence 330. In this sequence, dependencies are assigned a clear global order (for example, dependency A→E marked as ① is placed before dependency A→B marked as ②, while dependency B→C marked as ④ must be placed strictly after dependency A→B).

[0061] Next, when a request to query tables E and C is received, the necessary dependency path 350 connecting the baseline table (table A) to these two tables is calculated. A schematic diagram of this path filtering process is shown below. Figure 3 As shown in 340. Specifically, necessary dependency paths 350 include path one {A→E} and path two {A→B, B→C}. Since path {A→D, D→F} (i.e., the dashed part in 340) does not lead to any target table, it was not determined as a necessary dependency path, thus achieving "pruning" of tables D and F and effectively reducing query overhead.

[0062] Finally, when generating the physical query statement 360, the necessary dependencies (i.e., ①, ②, ④) on the necessary dependency paths are extracted and assembled strictly according to the order in the global dependency sequence 230. Since ① precedes ② in the global sequence, and ② precedes ④, the generated physical query statement will first execute the join (JOIN) between tables A and E, then the join with table B, and finally the join with table C. This mechanism not only eliminates redundant tables but also ensures that the physical join order strictly conforms to the predefined topological logic, avoiding syntax errors caused by disordered join order.

[0063] According to some embodiments, such as Figure 4 As shown, step S203, sorting multiple sets of dependencies based on the topology structure formed by multiple sets of dependencies, may include: step S401, determining the topological sorting of multiple physical tables based on the topology structure; and step S402, sorting multiple sets of dependencies based on the topological sorting of multiple physical tables to obtain a global dependency sequence, wherein the dependency on the physical table with a higher order in the topological sorting has a higher order in the global dependency sequence.

[0064] Therefore, by anchoring the order of dependencies to the topological sort of physical tables, it is ensured that in the generated global dependency sequence, the join operation of the dependent side always takes precedence over the dependent side. This approach avoids the missing reference error that may occur when generating physical query statements, ensuring that when joining each table, all its dependent tables have been joined, improving the syntactic correctness and execution stability of the final physical query statement, and enhancing the accuracy of the final data query results.

[0065] In some embodiments, topological sorting of physical tables refers to arranging all physical tables in the topology into a linear sequence such that for any dependency from table U to table V, table U always appears before table V in the sequence. This sorting result characterizes the hierarchical order of physical tables in terms of dependencies.

[0066] In some embodiments, in step S401, determining the topological sorting of the physical table can be implemented using a general graph theory algorithm, such as a sorting algorithm based on depth-first search (DFS).

[0067] In some embodiments, step S402, the specific implementation of sorting dependencies based on the topological sorting of physical tables, may include: determining the predecessor table for each dependency, and determining the order of the corresponding dependencies according to the position of the predecessor table in the topological sort. In other words, the earlier the predecessor table is in the topological sort, the earlier its corresponding dependency is in the global dependency sequence. For example, assuming the topological sorting result of the physical tables is table A, table E, table B, table C, table D, and table F, then regardless of the specific subsequent dependency pointers, all dependencies starting from table A (i.e., A→E, A→B, and A→D) are ranked before all dependencies starting from table B (i.e., B→C) in the global dependency sequence.

[0068] According to some embodiments, such as Figure 5 As shown, step S401, determining the topological sorting of multiple physical tables based on the topological structure, may include: step S501, initializing the in-degree information of multiple physical tables; step S502, determining the physical table with an in-degree of zero as the base table and adding it to the processing queue; and step S503, cyclically processing the physical tables in the processing queue until the processing queue is empty, including: step S5031, eliminating the dependency relationship with the currently processed physical table as the predecessor table and updating the in-degree of the remaining physical tables; step S5032, adding the updated physical table with an in-degree of zero to the processing queue; and step S5033, adding the currently processed physical table to the sorting list to obtain the topological sorting.

[0069] Therefore, by utilizing in-degree-based topological sorting, the baseline table that serves as the starting point for queries can be automatically identified, and all physical tables can be arranged in a linear order that conforms to dependencies. This approach ensures that the preceding tables required by each physical table added to the sorting results have been processed first, thus providing a reliable logical foundation for subsequently constructing correct physical table joins and improving the accuracy of the final data query results.

[0070] In some embodiments, in-degree information refers to the number of dependencies of a physical table as a successor table in the topology. An in-degree of zero typically means that the physical table does not depend on any other physical table, and is therefore suitable as a starting point for processing. The processing queue refers to a first-in, first-out (FIFO) cache structure used to temporarily store physical tables to be processed during algorithm execution. The sorted list here refers to the final result of the topology sort, i.e., an ordered list of all physical tables.

[0071] In some embodiments, in step S501, initializing the in-degree information can be achieved by traversing all dependencies in the topology. A counter can be maintained for each physical table, and whenever a physical table is found as a successor table in a dependency (e.g., table B in dependency A→B), the counter of that physical table is incremented by 1.

[0072] In some embodiments, in step S502, the counters of all physical tables can be scanned, and physical tables with a count result of zero can be marked as base tables and pushed into the processing queue.

[0073] In some embodiments, in step S503, cyclic processing refers to the process of continuously retrieving the current physical table from the head of the processing queue for processing. Specifically, eliminating dependencies in step S5031 means: finding all dependencies with the currently processed physical table as a predecessor table (for example, if table A is being processed, finding all relations of the form A→X), and decrementing the in-degree counter of the successor table (such as table X) in these relations by 1. Step S5032 checks whether any new physical tables have an in-degree of zero after the above operations; if so, it means that all predecessor dependencies of that physical table have been processed and it can be added to the processing queue to wait for the next step of processing. In step S5033, the processed physical tables can be recorded sequentially in the result list, and the final list is the topological sort of the physical tables.

[0074] According to some embodiments, such as Figure 6 As shown, step S204, determining the necessary dependency path from the base table to the target table based on the topology, may include: step S601, starting from the base table, sequentially accessing multiple physical tables based on the topology; step S602, in response to determining that the currently accessed physical table is not the target table and that there are neighboring tables that depend on the physical table, adding the dependency relationship between the physical table and the neighboring tables to the dependency path from the base table to the physical table, so as to obtain the dependency path from the base table to the neighboring tables; and step S603, in response to the currently accessed physical table being the target table, determining the dependency path from the base table to the physical table as a necessary dependency path.

[0075] Therefore, by accessing each physical table sequentially from the base table and dynamically constructing dependency paths to neighboring tables, the complete connection link from the base table to the target table can be accurately reconstructed. This path tracing mechanism ensures that the identified necessary dependency paths are logically connected and include all intermediate tables required for the connection, thus providing an accurate path basis for subsequently generating physical query statements.

[0076] In some embodiments, a neighbor table refers to a physical table in the topology that is directly dependent on or directly pointed to by the current physical table. For example, for the dependency relationship A→B, table B is a neighbor table of table A. A dependency path is a sequence of one or more consecutive dependencies that records the complete trajectory from the base table to the current physical table.

[0077] In some embodiments, in step S601, a data structure such as a queue or stack can be used to manage the physical tables to be accessed. During initialization, the base table and its corresponding initial path (usually empty or containing only the base table identifier) ​​are added to the data structure as the starting point for traversal.

[0078] In some embodiments, step S602, the sequential access to multiple physical tables embodies a path extension process. When the current physical table is retrieved, it is checked whether it is the target table. If it is not the target table, but the table points to other tables in the topology (i.e., it has neighboring tables), the dependency relationship "current table → neighboring table" can be appended to the existing dependency path of the current table, thereby generating a new path to the neighboring table, and the neighboring table and the new path are added to the queue to be accessed. This step ensures that the path grows continuously as the traversal process proceeds.

[0079] In some embodiments, in step S603, when it is identified that the currently accessed physical table is indeed the predetermined target table, the accumulated dependency path is marked as a necessary dependency path and saved. This path fully covers the entire process from the base table through all necessary intermediate tables to the target table.

[0080] According to some embodiments, the target table may include multiple target tables. For example... Figure 6 As shown, step S204, determining the necessary dependency path from the base table to the target table based on the topology, may include step S604, in response to determining that multiple target tables have been accessed, skipping access to other physical tables.

[0081] Therefore, by introducing an early termination mechanism for multi-target table scenarios, traversal can be stopped immediately after collecting the paths to all target tables. This approach avoids invalid scanning of the remaining irrelevant branches in the topology (i.e., those physical tables that neither contain target tables nor are on the path to the target tables), thereby further reducing the consumption of computing resources and shortening the time spent in the data query process.

[0082] In some embodiments, the premature termination of the necessary dependency path determination process can be triggered by detecting a termination condition. This typically means that it is not necessary to traverse all physical tables across the entire topology.

[0083] In an exemplary embodiment, a set of target tables to be accessed can be maintained, which is initialized to include all target tables involved in the logical query request. In step S604, whenever a target table is accessed during the traversal, it can be removed from the set. At the end of each loop iteration, it is checked whether the set is empty. If it is empty, it means that all target tables have been found, and the expansion and access to subsequent neighbor tables are stopped, and the necessary dependency paths that have been collected are directly output.

[0084] Understandably, other methods can also be used as termination conditions. For example, a counter can be set up, and the value recorded by the counter can be incremented by 1 each time a target table is accessed. If the value of the counter at the end of the loop iteration is consistent with the number of target tables, it means that all target tables have been found.

[0085] According to some embodiments, step S601, based on the topology, traversing multiple physical tables and their dependencies starting from the base table may include (not shown in the figure): step S6011, based on the topology, performing a breadth-first search on the multiple physical tables to determine the access order between physical tables of different depths in the multiple physical tables; and step S6012, based on the order in the global dependency sequence, determining the access order between physical tables of the same depth in the multiple physical tables.

[0086] Therefore, by combining breadth-first search (BFS) with a global dependency sequence, a deterministic traversal strategy is established. This strategy not only guarantees that physical tables closer to the base table are explored first, but also ensures that the order in which physical tables are accessed at the same level is consistent with the pre-computed global topology order. This helps improve the stability of the generated physical query statements when there are multiple potential paths or when join priorities need to be determined.

[0087] In some embodiments, breadth-first search is used to access physical tables layer by layer outward from the base table, according to the "depth" of each physical table. Different depths refer to the dependency distance of a physical table relative to the base table; for example, the base table has a depth of 0, the base table's direct neighbor table has a depth of 1, and so on.

[0088] In some embodiments, in step S6011, a first-in-first-out (FIFO) queue structure can be used to implement hierarchical access, ensuring that access to physical tables at depth N+1 will only begin after all physical tables at depth N have been accessed.

[0089] In some embodiments, in step S6012, when it is necessary to add multiple neighbor tables of the current physical table to the queue, the relative positions of these neighbor tables in the global dependency sequence can be queried, and these neighbor tables of the same depth can be added to the queue in the order in which they appear in the global sequence. For example, if the current table A points to both table B and table E, and A→E is listed before A→B in the global sequence, then table E will be added to the queue first, indicating that it will be accessed first.

[0090] According to some embodiments, the logical wide table predefines the mapping relationship between multiple logical fields and multiple physical fields in multiple physical tables. Step S202, parsing the logical query request to determine the target table corresponding to the logical query request in multiple physical tables may include (not shown in the figure): step S2021, parsing the logical query request to determine the target logical field to be queried among multiple logical fields; and step S2022, based on the mapping relationship, determining the physical field corresponding to the target logical field, and determining the physical table to which the corresponding physical field belongs as the target table.

[0091] Therefore, by accurately parsing logical fields into physical tables based on predefined mapping relationships, precise location of data storage can be achieved, avoiding invalid retrieval caused by fuzzy matching or full scans. This precise location mechanism ensures that subsequent path construction revolves only around the physical tables that actually contain the data, thereby significantly narrowing the scope of data queries, reducing the I / O overhead and computing resource consumption of the underlying database, and improving the accuracy of the data source for queries.

[0092] In some embodiments, a logical field refers to an attribute defined in a logical wide table and named using business terms, such as "user age" or "order amount". A physical field refers to a column that actually exists in a physical table in the physical data warehouse, such as the "user_age" column in the "user_info" table. A mapping relationship refers to a key-value pair or corresponding table stored in the metadata system, which specifies which physical field in which physical table each logical field originates from.

[0093] In some embodiments, in step S2021, the logical query request may be parsed to extract a list of fields used to specify the returned results, and these fields may be identified as target logical fields. In one embodiment, the target logical fields may include, for example, fields following the SELECT clause in SQL, or a list of fields in API request parameters.

[0094] In some embodiments, in step S2022, the identified target logical field can be used as an index key to search within a pre-stored mapping relationship. For each target logical field, its mapped physical field identifier can be obtained, and the physical table identifier can be extracted from it. Finally, the set of all extracted physical table identifiers after deduplication can be determined as the set of target tables corresponding to the logical query request.

[0095] According to some embodiments, such as Figure 7 As shown, the data query method 700 may further include: step S706, receiving the user identity information of the initiator of the logical query request; step S707, converting the user identity information into system macro variables; and step S708, injecting the system macro variables as filtering conditions into the physical query statement.

[0096] It is understandable that the operations and effects of steps S701-S705 and S709 in method 700 can be referred to the description of steps S201-S206 in method 200 above, and will not be repeated here.

[0097] Therefore, by dynamically converting user identities into macro variables and injecting them into physical queries, fine-grained data access control is achieved during the query process. This mechanism ensures that the same logical model can return differentiated data results for different users, achieving secure data isolation and improving data access security. Simultaneously, since it eliminates the need to repeatedly create multiple physical views or copies for users with different permissions, it reduces system storage overhead and maintenance costs.

[0098] In some embodiments, user identity information refers to data used to uniquely identify the entity initiating the query request and its organizational structure or permission group. System macro variables are placeholder variables (e.g., ${current_user_id}) predefined in the query generation engine that can be dynamically replaced at runtime. Filtering conditions are logical expressions (e.g., the WHERE clause in SQL) used to limit the range of data returned.

[0099] According to some embodiments, user identity information may include at least one of the following: the user identifier of the currently logged-in user, the user's department identifier, or the user's role identifier.

[0100] In some embodiments, in step S706, the user identity information of the data query initiator can be extracted from the session context in which the connection was established, the HTTP request header, the authentication token, or other content.

[0101] In some embodiments, in step S707, a context environment object can be maintained to map the extracted user identifier, department identifier, and other information into standardized macro variables within the system.

[0102] In some embodiments, in step S708, the injection of filtering conditions is typically performed during the construction of the physical query statement. Specifically, the syntax structure of the physical query statement can be parsed to check whether the logical wide table is configured with permission rules. If such rules exist, corresponding database filtering clauses can be generated and appended to the condition part of the physical query statement, thereby enforcing data filtering at the physical layer.

[0103] In one exemplary embodiment, a row-level permission rule of "Allow only viewing data within this department" is configured in the logical wide table, and the current user's department identifier has been converted to the macro variable $dept_id. In this case, a database filter clause of the form AND department_id = $dept_id can be generated and appended to the WHERE clause of the physical query statement. This ensures that the final executed SQL statement automatically includes the restriction, guaranteeing that the user can only access data within their authorized scope.

[0104] According to some embodiments, such as Figure 8 As shown, step S205, converting at least one necessary dependency relationship included in the necessary dependency path into physical table join relationships, and sequentially combining physical table join relationships according to the order of at least one necessary dependency relationship in the global dependency relationship sequence to obtain a physical query statement, may include: step S801, generating a source clause based on the base table; step S802, converting at least one necessary dependency relationship into a join clause; and step S803, starting with the source clause, sequentially appending and concatenating the join clauses according to the order of the necessary dependency relationships in the global dependency relationship sequence to obtain a physical query statement.

[0105] Therefore, by deconstructing the physical query statement construction process into three steps—defining the source clause, transforming the join clause, and orderly concatenation—modularization and standardization of query statement generation are achieved. This structured assembly method ensures that the final generated query statement strictly conforms to the syntax structure specifications of the underlying database language, enabling the FROM clause and JOIN clause to be correctly connected in terms of statement structure, thereby improving the efficiency and accuracy of generating complex nested query statements.

[0106] In some embodiments, the source clause refers to a syntactic segment in a query statement used to declare the main query table, such as the FROM Table_Name clause in standard SQL. The join clause refers to a syntactic segment used to declare a join operation between tables, typically containing join operators and join conditions, such as JOIN Table_B ON Table_A.Key = Table_B.Key in standard SQL.

[0107] In some embodiments, in step S801, the physical table name of the base table can be extracted and, in conjunction with the syntax rules of the data query language (such as the FROM keyword), a source clause can be generated.

[0108] In some embodiments, in step S802, each dependency in the necessary dependency path can be traversed. For each dependency, the downstream table of that dependency (e.g., table B in dependency A→B) can be identified as the join target, and predefined association fields can be obtained to generate the corresponding join clause.

[0109] In some embodiments, in step S803, an empty query build buffer can be created first, and the source clause generated in step S801 can be filled in as the header. Then, based on the global dependency sequence obtained in step S203, the relative order of each necessary dependency can be determined. According to this relative order, the corresponding join clauses are retrieved sequentially and appended to the source clause in the buffer. For example, if the global sequence shows that dependency ① is listed before dependency ②, then the JOIN clause corresponding to dependency ① will be joined first. In this way, scattered clauses can be combined into a logically coherent and syntactically correct physical query statement.

[0110] According to some embodiments, step S205, converting the necessary dependencies included in the necessary dependency path into physical table joins, and sequentially combining physical table joins according to the order of the necessary dependencies in the global dependency sequence to obtain a physical query statement, may include: generating a structured query language statement adapted to the database type to which the target table belongs.

[0111] Therefore, by generating specific structured query language statements for different underlying database types, the syntactic differences between heterogeneous databases are resolved. This adaptive dialect generation mechanism ensures that physical query statements can be correctly parsed and executed by the underlying specific database engine, thereby improving system compatibility and the success rate of cross-data source queries.

[0112] In some embodiments, database type refers to the category of the specific database product that hosts the physical tables, including but not limited to MySQL, Oracle, PostgreSQL, SQL Server, or various big data engines (such as Doris and ClickHouse). Although Structured Query Language has standard specifications, different databases have dialectal differences in their specific syntax implementations.

[0113] In some embodiments, the database type configuration for each physical table can be pre-recorded in the data model. When generating physical query statements, the system invokes the corresponding dialect adapter based on this configuration. In an exemplary embodiment, if the target table is located in a MySQL database, the adapter will wrap the table name in backticks; if it is located in an Oracle database, double quotes may be used.

[0114] According to some embodiments, logical query requests may be received via the Java Database Connectivity Protocol or the Open Database Connectivity (ODBC) protocol.

[0115] Therefore, by supporting common standard database connection protocols, the data query method disclosed herein can be seamlessly integrated with existing business intelligence tools, reporting software, or business systems. Upper-layer applications do not require code refactoring or access via private APIs; they only need to replace the database driver to easily access logical wide tables, thereby reducing the development cost of system integration and improving the system's compatibility, versatility, and scalability.

[0116] According to another aspect of this disclosure, a data query apparatus is provided. For example... Figure 9 As shown, the apparatus 900 includes: a receiving unit 910 configured to receive a logical query request for a logical wide table, the logical wide table being constructed based on multiple physical tables, and the multiple physical tables having multiple sets of dependencies; a parsing unit 920 configured to parse the logical query request to determine the target table to be queried among the multiple physical tables; a sorting unit 930 configured to sort the multiple sets of dependencies based on a topology structure to obtain a global dependency sequence and a base table among the multiple physical tables; a determining unit 940 configured to determine the necessary dependency paths connecting the base table to the target table based on the topology structure; a combining unit 950 configured to convert the necessary dependency relationships included in the necessary dependency paths into physical table join relationships, and sequentially combine the physical table join relationships according to the order of the necessary dependency relationships in the global dependency sequence to obtain a physical query statement; and a querying unit 960 configured to perform data querying using the physical query statement.

[0117] It is understood that the operation and effects of units 910-960 in device 900 can be referred to the description of steps S201-S206 in method 200 above, and will not be repeated here.

[0118] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0119] According to embodiments of this disclosure, an electronic device, a readable storage medium, and a computer program product are also provided.

[0120] refer to Figure 10 The present invention describes a structural block diagram of an electronic device 1000 that can serve as a server or client of the present disclosure, which is an example of a hardware device that can be applied to various aspects of the present disclosure. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0121] like Figure 10 As shown, the electronic device 1000 includes a computing unit 1001, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 1002 or a computer program loaded from a storage unit 1008 into a random access memory (RAM) 1003. The RAM 1003 may also store various programs and data required for the operation of the electronic device 1000. The computing unit 1001, ROM 1002, and RAM 1003 are interconnected via a bus 1004. An input / output (I / O) interface 1005 is also connected to the bus 1004.

[0122] Multiple components in electronic device 1000 are connected to I / O interface 1005, including: input unit 1006, output unit 1007, storage unit 1008, and communication unit 1009. Input unit 1006 can be any type of device capable of inputting information to electronic device 1000. Input unit 1006 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device, and may include, but is not limited to, a mouse, keyboard, touchscreen, trackpad, trackball, joystick, microphone, and / or remote control. Output unit 1007 can be any type of device capable of presenting information, and may include, but is not limited to, a monitor, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 1008 may include, but is not limited to, a hard disk and an optical disk. The communication unit 1009 allows the electronic device 1000 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers and / or chipsets, such as Bluetooth devices, 802.11 devices, WiFi devices, WiMax devices, cellular communication devices and / or the like.

[0123] The computing unit 1001 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1001 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1001 performs the various methods, processes, and / or processing described above. For example, in some embodiments, these methods, processes, and / or processing may be implemented as computer software programs tangibly contained in a machine-readable medium, such as storage unit 1008. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 1000 via ROM 1002 and / or communication unit 1009. When the computer program is loaded into RAM 1003 and executed by the computing unit 1001, one or more steps of the methods, processes, and / or processing described above may be performed. Alternatively, in other embodiments, the computing unit 1001 may be configured to perform these methods, processes, and / or handling by any other suitable means (e.g., by means of firmware).

[0124] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0125] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0126] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0127] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0128] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), the Internet, and blockchain networks.

[0129] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is established by computer programs running on the respective computers and having a client-server relationship with each other. A server can be a cloud server, also known as a cloud computing server or cloud host, a hosting product within the cloud computing service ecosystem, addressing the shortcomings of traditional physical hosts and VPS (Virtual Private Server, or simply "VPS") services, such as high management difficulty and weak business scalability. Servers can also be servers for distributed systems or servers incorporating blockchain technology.

[0130] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be performed in parallel, sequentially, or in a different order, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0131] While embodiments or examples of this disclosure have been described with reference to the accompanying drawings, it should be understood that the methods, systems, and devices described above are merely exemplary embodiments or examples, and the scope of this disclosure is not limited by these embodiments or examples, but only by the granted claims and their equivalents. Various elements in the embodiments or examples may be omitted or replaced by their equivalents. Furthermore, the steps may be performed in a different order than that described in this disclosure. Further, various elements in the embodiments or examples may be combined in various ways. Importantly, as technology evolves, many elements described herein can be replaced by equivalents that appear after this disclosure.

Claims

1. A data query method, comprising: receiving a logical query request for a logical wide table, the logical wide table being constructed based on a plurality of physical tables, the plurality of physical tables having a plurality of sets of dependency relationships therebetween; parsing the logical query request to determine a target table to be queried among the plurality of physical tables; sorting the plurality of sets of dependency relationships based on a topology structure formed by the plurality of sets of dependency relationships to obtain a global dependency relationship sequence and a reference table among the plurality of physical tables; determining a necessary dependency path from the reference table to the target table based on the topology structure; converting at least one necessary dependency relationship included in the necessary dependency path into a physical table connection relationship respectively, and combining the physical table connection relationships in sequence according to the order of the at least one necessary dependency relationship in the global dependency relationship sequence to obtain a physical query statement; and performing data query by using the physical query statement. The sorting the plurality of sets of dependency relationships based on a topology structure formed by the plurality of sets of dependency relationships to obtain a global dependency relationship sequence and a reference table among the plurality of physical tables comprises: determining a topological sorting of the plurality of physical tables based on the topology structure; and sorting the plurality of sets of dependency relationships based on the topological sorting of the plurality of physical tables to obtain the global dependency relationship sequence, wherein a dependency relationship that depends on a physical table with an earlier order in the topological sorting has an earlier order in the global dependency relationship sequence. The determining a topological sorting of the plurality of physical tables based on the topology structure comprises: initializing in-degree information of the plurality of physical tables; determining a physical table with an in-degree of zero as the reference table and adding the physical table to a processing queue; and circularly processing the physical tables in the processing queue until the processing queue is empty, comprising: eliminating dependency relationships that have the currently processed physical table as a preceding table and updating in-degrees of the remaining physical tables; adding the physical tables with updated in-degrees of zero to the processing queue; and adding the currently processed physical table to a sorting list. The determining a necessary dependency path from the reference table to the target table based on the topology structure comprises: sequentially accessing the plurality of physical tables starting from the reference table based on the topology structure; in response to determining that a currently accessed physical table is not the target table and there is a neighbor table that depends on the physical table, adding a dependency relationship between the physical table and the neighbor table to a dependency path from the reference table to the physical table to obtain a dependency path from the reference table to the neighbor table; and in response to the currently accessed physical table being the target table, determining the dependency path from the reference table to the physical table as the necessary dependency path. The target table comprises a plurality of target tables, and the determining a necessary dependency path from the reference table to the target table based on the topology structure comprises: in response to determining that the plurality of target tables have all been accessed, skipping access to other physical tables. The sequentially accessing the plurality of physical tables starting from the reference table based on the topology structure comprises: ​ ​ ​ ​ ​ ​ 2. The method of claim 1, wherein, ​ ​ ​ 3. The method of claim 2, wherein, ​ ​ ​ ​ ​ ​ ​ 4. The method of any one of claims 1 to 3, wherein, ​ ​ ​ ​ 5. The method of claim 4, wherein, ​ ​ 6. The method of claim 4, wherein, ​ perform a breadth-first search on the plurality of physical tables based on the topology to determine an access order between physical tables of different depths in the plurality of physical tables; and determine an access order between physical tables of the same depth in the plurality of physical tables based on the order in the global dependency sequence.

7. The method of any one of claims 1 to 6, wherein, The logical wide table pre-defines a mapping relationship between a plurality of logical fields and a plurality of physical fields in the plurality of physical tables, and the parsing the logical query request to determine a target table corresponding to the logical query request in the plurality of physical tables comprises: parsing the logical query request to determine a target logical field to be queried in the plurality of logical fields; and determining a physical field corresponding to the target logical field based on the mapping relationship, and determining a physical table to which the corresponding physical field belongs as the target table.

8. The method of any one of claims 1-6, further comprising: receiving user identity information of an initiator of the logical query request; converting the user identity information into a system macro variable; and injecting the system macro variable as a filter condition into the physical query statement. The user identity information comprises at least one of the following: a user identifier of a currently logged-in user, a department identifier to which the user belongs, or a user role identifier.

9. The method of claim 8, wherein, The converting the at least one necessary dependency relationship included in the necessary dependency path into a physical table join relationship respectively, and sequentially combining the physical table join relationships according to the order of the at least one necessary dependency relationship in the global dependency sequence to obtain a physical query statement comprises:

10. The method of any one of claims 1 to 6, wherein, generating a FROM clause based on the reference table; converting the at least one necessary dependency relationship into a JOIN clause respectively; and sequentially appending and splicing the JOIN clauses according to the order of the necessary dependency relationships in the global dependency sequence, starting from the FROM clause, to obtain the physical query statement. The converting the at least one necessary dependency relationship included in the necessary dependency path into a physical table join relationship respectively, and sequentially combining the physical table join relationships according to the order of the at least one necessary dependency relationship in the global dependency sequence to obtain a physical query statement comprises:

11. The method of any one of claims 1 to 6, wherein, generating a structured query language statement adapted to a database type to which the target table belongs. The logical query request is received via a Java Database Connectivity protocol or an Open Database Connectivity protocol.

12. The method of any one of claims 1 to 6, wherein, 13. A data query apparatus, comprising: a receiving unit configured to receive a logical query request for a logical wide table, the logical wide table being constructed based on a plurality of physical tables, the plurality of physical tables having a plurality of sets of dependency relationships therebetween; a parsing unit configured to parse the logical query request to determine a target table to be queried in the plurality of physical tables; an ordering unit configured to order the plurality of sets of dependency relationships based on a topology constituted by the plurality of sets of dependency relationships to obtain a global dependency sequence and a reference table in the plurality of physical tables; a determining unit configured to determine a necessary dependency path from the reference table to the target table based on the topology. ​ The combination unit is configured to convert the necessary dependency relationship included in the necessary dependency path into a physical table connection relationship, and combine the physical table connection relationship in sequence according to the order of the necessary dependency relationship in the global dependency relationship sequence to obtain a physical query statement; and The query unit is configured to perform data query by using the physical query statement.

14. An electronic device, comprising: The electronic device comprises: at least one processor; and a memory connected with the at least one processor in communication; wherein The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-12.

15. A non-transitory computer-readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to enable a computer to perform the method of any one of claims 1-12.

16. A computer program product comprising a computer program, wherein, The computer program, when executed by a processor, implements the method of any one of claims 1-12.

Images