Data authority control system based on data entity low decoupling

Abstract

The invention relates to the field of data information, in particular to a data authority control system based on data entity low decoupling, which comprises a data authority management server used for processing data authority rules and generating new SQL (Structured Query Language) conditions, the authority controllers are used for being injected into a service system needing to be subjected to authority management based on the data entity to enable the service system to have data authority control capability, and data interaction is carried out between the data authority management server and the authority controllers through a data transmission unit. The data permission control system established by adopting the JAVA + Spring framework can manage data permissions of multiple dimensions, solves the problem of high coupling of a service system and a data permission function by adopting a low-coupling design mode, also avoids the development cost that new and old systems need the data permission function, and improves the development efficiency. And the development cost and the integration difficulty required by the data permission are greatly reduced.

Description

Technical Field

[0001] The present invention relates to the field of data information, and in particular to a data authority control system based on low decoupling of data entities. Background Art

[0002] Currently, when designing traditional business systems (e.g., inventory management systems), multiple different organizations are designed so that each tree-structured organization can view the data of its child nodes through the parent node, as described in "A Data Permission Control Method, Device, Electronic Device, and Storage Medium" (publication number CN116756727B). However, this structural form still has many drawbacks, such as:

[0003] During the development of data permission control, specific SQL statements must be intercepted. This requirement necessitates that those responsible for developing project functionality have a certain understanding of business logic. This is because only with a familiar business can one clearly grasp the specific scenarios and rules for data access, and thus accurately determine the correspondence between identifiers and permissions when configuring intercepted data permission flags.

[0004] For example, in an enterprise resource planning (ERP) system, employees in different departments have different access permissions to different types of data in the database. Only by understanding each department's business functions and data usage requirements can developers configure permission identifiers for sales employees to only access customer order data, while configuring permission identifiers for finance employees to access financial report data.

[0005] This configuration approach is labor-intensive. Because it requires meticulously configuring the association between each permission identifier and the corresponding permission for different business scenarios and data access requirements, and because business scenarios are often complex and diverse, involving numerous data tables and operation types, configuration becomes tedious and time-consuming.

[0006] Furthermore, the person responsible for configuring identifiers needs to possess a certain level of coding knowledge. This is because in this system, permission identifiers are identified by IDs in the object-relational mapping (ORM) framework. The ORM framework is a technology that maps database data to objects in a program, and its ID is the key information used to uniquely identify records or objects in a database table. Configurators need to understand the working principles and code structure of the ORM framework in order to accurately obtain and use these IDs to configure permission identifiers, ensuring that the system can correctly identify and execute the corresponding permission control rules.

[0007] In summary, intercepting specific SQL requires developers to be familiar with the business and configuration personnel to have certain coding knowledge. It also brings a large configuration workload. These factors increase the difficulty, cost, and complexity of data permission control development.

[0008] (2) System configuration involving business identification and data permission identification must be performed separately on both the client and server sides. This means that both business identification (specific markers used to identify and distinguish different business functions or business processes) and data permission identification (identification information used to define user rights to access and operate data) must be configured separately on the client and server sides, or set up according to unified specifications.

[0009] In certain business scenarios or system requirements, in addition to conventional configuration, it is also necessary to write dedicated configuration classes on the server side. However, this undoubtedly further increases the configuration workload of developers and significantly increases the configuration content that needs to be processed and maintained.

[0010] From a development perspective, since both the client and server must be configured, and their configurations must match and work together, this requires front-end and back-end alignment at the development level. Front-end and back-end alignment means that the front-end and back-end development teams reach consensus on business logic, data formats, interface specifications, and other aspects to ensure proper client and server interaction and collaboration. To achieve this, front-end and back-end developers need to communicate frequently to clarify their respective configurations, configuration methods, and interdependencies. This process consumes a significant amount of time and effort, significantly increasing communication costs.

[0011] Furthermore, during joint debugging and testing after development, due to the complexity and interdependence of front-end and back-end configurations, various compatibility issues and logical errors may arise. For example, inconsistent data permissions configured on the client and the server may lead to permission anomalies during client operations. Or, different parsing methods for business identifiers on the front-end and back-end may cause incorrect execution of business processes. To resolve these issues, front-end and back-end developers need to work closely together to gradually troubleshoot and fix the problems, which further increases the cost of joint debugging.

[0012] To summarize, configuring business identifiers and data permission identifiers separately on the client and server, especially when writing configuration classes on the server, will make the developer's configuration work complicated and will also significantly increase the communication and joint debugging costs during the front-end and back-end development process.

[0013] (3) When implementing data permission control using the technical solution disclosed in CN116756727B, the existing architectural design makes it difficult to effectively reuse and expand the system across different projects. In actual applications, this leads to numerous problems, such as code redundancy, low development efficiency, and maintenance difficulties. In other words, if data permission control is achieved using the technical solution disclosed in CN116756727B, its integration with the business system and its architectural impact must be considered. Assuming that the business system is deployed on a server in the form of an application or software, then to achieve data permission control integration, this technical solution must be integrated into a functional module of the business system software. However, this technical solution has architectural design limitations. In this solution, the logic related to data permission functions and user roles is written within the same functional module. The business system and the data permission control module are located in the same application service. From a computer system perspective, they run in the same process. This architectural implementation method has serious deficiencies in reusability. From the perspective of software reuse, when different engineering projects (such as Project A and Project B) need to use this technical solution to implement data permission control, each project must independently integrate the data permission control module into its own system. This means that each project must couple the relevant data permission code into its own code system, resulting in a large amount of duplicate data permission code between different projects. This situation is extremely detrimental to the scalability and reusability of the system. In short, the technical solution disclosed in CN116756727B has great difficulties and limitations in terms of functional expansion and reuse:

[0014] From the perspective of scalability, because the data permission code is tightly coupled with each project, when business requirements change and the data permission control logic needs to be expanded or modified, the operation must be performed separately in each project. This not only increases the development workload but also easily introduces inconsistencies.

[0015] From the perspective of reusability, the data permission control module cannot be shared as an independent, reusable component between different projects, which reduces development efficiency and increases maintenance costs.

[0016] (4) The server-side data permission control adopts a componentized design pattern, and its core implementation mechanism is aspect interception based on the SQL statement level. This pattern intercepts the complete SQL execution chain under the target business scenario by implanting a unified permission verification component in the system data access layer, thereby realizing data access permission control for specific functional points. Due to the strong coupling between the system business logic and permission control, it is necessary to perform intrusive transformation on the existing SQL execution chain and reconstruct the permission verification logic of the existing business code, so it is necessary to perform intrusive transformation on the existing SQL execution chain. Moreover, in many complex business scenarios, there are adaptation challenges of multiple data sources and multiple database types, involving the transformation of a large number of related systems (such as transaction management, caching mechanism, etc.), and it is necessary to sort out the permission control requirements of a large number of existing functional modules. Therefore, this method is extremely cumbersome for the transformation of existing systems and is very difficult to integrate. It is only applicable to new systems and its implementation effect is good.

[0017] How to reduce the high coupling impact between traditional business systems and data permission modules has always been an urgent problem to be solved in this field. Summary of the Invention

[0018] The purpose of the present invention is to address the corresponding deficiencies in the existing technology and provide a data permission control system based on low decoupling of data entities. The data permission control system is established using the JAVA+Spring framework to manage data permissions in multiple dimensions. The low-coupling design method solves the problem of high coupling between business systems and data permission functions, avoids the development cost of data permission functions required for new and old systems, and greatly reduces the development cost and integration difficulty required for data permissions.

[0019] The purpose of the present invention is to adopt the following scheme to achieve:

[0020] A data authority control system based on low decoupling of data entities, comprising a data authority management server and a plurality of authority controllers, wherein the data authority management server and the authority controllers interact with each other via a data transmission unit;

[0021] The data authority management server is used to process data authority rules and generate new SQL conditions;

[0022] The permission controller is used to be injected into a business system that needs to perform data entity-based permission management, so that the business system has data permission control capabilities.

[0023] Preferably, the data rights management server includes an application configuration unit, a data entity unit, and a dimension rights processing unit:

[0024] The application configuration unit is used for parameter configuration of the data rights management server;

[0025] The data entity unit is used to define and manage the permission rules of data entities, and implement fine-grained permission control over database tables or table sets in the business system;

[0026] The dimension permission processing unit is used to perform fine-grained data access control between the application layer and the database when the business system initiates a database operation request.

[0027] Preferably, the fine-grained data access control includes:

[0028] ①SQL interception and parsing

[0029] The permission controller monitors the database connection channel in real time, captures the original SQL statement through protocol parsing technology, and extracts the request context information (including user ID, application ID, operation type, etc.);

[0030] ②Acquisition of permission strategy

[0031] The permission controller passes the request parameters to the data permission management server and obtains the pre-configured permission policy set through the application ID index;

[0032] ③Data entity processing

[0033] Perform semantic analysis on SQL to identify the data tables involved, and dynamically generate table association conditions or add filtering conditions based on permission policies;

[0034] ④SQL reconstruction and execution

[0035] The processed SQL statements are forwarded to the target database for execution, and the execution results are encapsulated in a standard data format and returned to the business system.

[0036] Preferably, the application configuration unit includes an APP configuration module, a dimension configuration module, and a data entity configuration module:

[0037] The APP configuration module is used to manage the registration information and authentication parameters of the business system in the data rights management server to ensure the security of rights control and service interaction in a multi-user environment;

[0038] The dimension configuration module is used to define, manage and apply dimension information

[0039] The data entity configuration module is used to configure the control relationship between data tables (data entities) and dimensions on the hit tables in actual SQL by establishing mapping rules between data entities, dimension attributes and physical database objects, thereby achieving fine-grained control over the SQL execution process.

[0040] Preferably, the data entity unit includes a table processing module and an SQL condition processing module:

[0041] The table processing module is used for SQL table structure analysis, table-level permission filtering, multi-table connection condition integration and dynamic SQL reorganization;

[0042] The SQL condition processing module is used for parsing, authority matching, and dynamic adjustment of the SQL condition part.

[0043] Preferably, the authority controller includes a business system configuration unit, a custom control unit, and an SQL interception unit.

[0044] The business system configuration unit is used to perform basic configuration on the business system;

[0045] The custom control unit is used to precisely control the data permissions of a specific table for query operations involving multiple tables, including data table transfer and access control, as well as flexible settings for query dimensions, so that staff can perform data queries through custom dimensions;

[0046] The SQL interception unit is used to parse and process the table and condition parts of the select clause in the SQL statement in the business system, combine the user's dimension nodes and the strength control information of the custom control unit, form a new SQL condition and send it to the data rights management server;

[0047] Preferably, the business system configuration unit includes a cache setting module, a communication setting module, and an identity setting module:

[0048] The cache setting module is used to cache tables and conditions after processing in the data permission server, avoiding the need to spend a lot of time searching in the data permission list each time, saving communication costs and processing algorithm costs; in fact, it adopts a multi-level cache architecture to achieve efficient reuse of permission processing results, thereby reducing system response delays by pre-storing calculation results;

[0049] The communication setting module is used to set data communication parameters between the data rights management server and the business system;

[0050] The identity setting module is used to configure user identity information of the business system.

[0051] Preferably, the custom control unit includes an authority control switch, a table pass module, and a custom dimension module:

[0052] The permission control switch is used to dynamically balance system security and flexibility under the global data permission policy, and temporarily open and close the permission control logic for specific business scenarios or SQL operations;

[0053] The table pass module is used to process data table front-line transfer or access control;

[0054] The custom dimension module is used to enable developers to dynamically add new data dimensions to SQL queries based on specific business needs, and flexibly select the logical relationships between these dimensions (such as OR and AND), thereby achieving more accurate and personalized data screening and querying.

[0055] The beneficial effects of the present invention are as follows:

[0056] ① This invention implements SQL permission control through the abstract concept of data entities. Its core lies in using database tables or table collections as the control unit, rather than directly intercepting specific SQL statements. This design significantly reduces the complexity and technical threshold of permission configuration, specifically including:

[0057] 1.1 Definition and Identification of Data Entities

[0058] 1.1.1 The data entity used in this invention is an abstract encapsulation of a database table or table collection, which is used to identify data objects that require permission control (such as the employees table, and the orders and customers association table).

[0059] 1.1.2 The business identifier used in this invention is a unique identifier for a data entity (e.g., HR_EMPLOYEE), which is predefined by the system and bound to a physical table. Business personnel or operations personnel can define permission rules by configuring the business identifier rather than a specific table name or SQL statement.

[0060] 1.2 Simplified logic of permission configuration

[0061] 1.2.1 Configuring Objects: Traditional methods require configuring permission rules for each SQL statement, while this invention directly associates permission rules with the business identifier of the data entity. For example, when configuring permissions for the HR_EMPLOYEE entity, all SQL operations involving that entity (such as query and update) automatically inherit the permission rules.

[0062] 1.2.2 Configuration method: Through the visual interface or configuration file, users only need to select the business identifier of the data entity and set dimension conditions (such as organizational hierarchy and job role) to complete the deployment of permission rules without writing or understanding SQL code.

[0063] 1.3 SQL interception and control process is simple

[0064] 1.3.1 Match Verification: Before executing SQL, the system first parses the tables involved in the SQL and matches them with the business identifiers of the data entities. If a match is found for a configured entity (e.g., the employees table corresponds to the HR_EMPLOYEE identifier), the permission control logic is triggered; otherwise, the request is directly released.

[0065] 1.3.2 Dynamic rule generation: Based on the permission configuration of the data entity (such as dimension conditions), the system automatically generates the corresponding SQL filter conditions (such as WHERE department_id = 'D001') and injects them into the original SQL to implement data filtering.

[0066] 1.4 More technical advantages than traditional methods

[0067] 1.4.1 Reduce coupling:

[0068] The traditional method requires hard-coding permission logic into business code or SQL interceptors, which is highly coupled with business functions.

[0069] The present invention externalizes the authority rules through data entities, and the business system only needs to call the authority service through the interface to achieve physical decoupling.

[0070] 1.4.2 Improve configuration efficiency:

[0071] The traditional method requires configuring permissions for each SQL statement or function point separately, which is labor-intensive and error-prone.

[0072] The present invention covers all associated operations through global configuration of data entities, thereby significantly reducing configuration costs.

[0073] 1.4.3 Enhanced scalability:

[0074] When adding a new data entity, the present invention only needs to add a business identifier and rules in the authority service without modifying the business code or SQL statement.

[0075] The present invention supports complex scenarios (such as multi-table association queries) and implements unified authority control through relationship mapping between data entities.

[0076] In summary, this invention elevates SQL permission control from the code level to the data model level by abstracting data entities and binding them to business identifiers. This enables code-free configuration, globalization of permission rules, and system decoupling, providing an efficient, flexible, and easily scalable solution for enterprise-level data permission management. For example, if the data entity HR_EMPLOYEE is configured with the rule "Only department managers are allowed to view the salaries of employees in their department," all salary query SQL statements involving the employees table will automatically have the condition "WHERE department_id = current_user_dept()" added, eliminating the need to rewrite filtering logic in the business code.

[0077] ② This invention makes innovative improvements in data permission configuration, abandoning the traditional way of integrating data permission configuration in the business system and adopting a service-based configuration method. It effectively solves the problems of reusability and coupling, and realizes efficient separation of business system and data permission management. Specifically, it includes:

[0078] 2.1 Characteristics and advantages of service-based configuration

[0079] 2.1.1 Separation of Configuration and Operation: This invention separates data permission configuration from the business system, using a dedicated independent application for data permission configuration. Business systems no longer need to worry about the specific configuration details of data permissions and can focus entirely on business development and function maintenance, avoiding the additional costs associated with front-end and back-end data permission processing.

[0080] 2.1.2 Reduced Professional Requirements: This design approach eliminates the need for business personnel to possess development technical knowledge when configuring data permissions, allowing them to focus solely on configuring data permissions. Developers also don't need to have a comprehensive understanding of the business. By separating personnel categories and work items, the "professionals do their job" approach is achieved, improving work efficiency and configuration accuracy.

[0081] 2.2 Deployment independence of business systems and data authority services

[0082] 2.2.1 Flexible Deployment Mode: When implementing data permission control, the business system can be deployed independently on the business server, and the data permission service can be deployed independently on the data permission management server or on the business server. Regardless of the deployment method adopted, the present invention ensures that the business system and the data permission management server are independent applications or software on the physical server.

[0083] 2.2.2 Reduce coupling: Business systems can use data rights management servers to control data rights according to standard configurations, separating data rights-related matters from the business system, significantly reducing the coupling between the business system and data rights management.

[0084] 2.3 Independence of data processing and optimization of development division of labor

[0085] 2.3.1 Data Processing Decoupling: This invention places all SQL splitting, combining, and concatenating operations within the data permission service, completely decoupling it from the business system. This allows business system developers to focus on business system development without having to worry about the complexities of data permission processing.

[0086] 2.3.2 Solve the reusability and coupling problems: Business personnel only need to control data permissions in the service-based data permission application. This approach effectively solves the problems of poor reusability and high coupling in traditional methods, improves the maintainability and scalability of the system, and also provides a unified and efficient solution for data permission management between different business systems.

[0087] ③ This invention has a unique concept and significant advantages in data rights management. Its core is to shift the focus from the traditional system function level to the data model level, thereby greatly simplifying the configuration of rights rules. It is applicable to projects at different development stages, including:

[0088] 3.1 Focus on data models rather than system functions

[0089] Traditional data permission management often revolves around system functions, tightly binding permission control to specific functional operations. For example, when designing an enterprise management system, permission rules may be set for specific functions such as "employee information query" and "order processing". The present invention breaks through this limitation and focuses on the data model. The data model is an abstract representation of real-world data, covering aspects such as the structure, relationships, and constraints of the data. The present invention directly manages permissions for data entities in the database (such as database tables, views, etc.), focusing on the access rules of the data itself, rather than setting permissions based on system functions.

[0090] 3.2 Decoupling Advantages When Configuring Permission Rules

[0091] When configuring permission rules, the present invention achieves the decoupling of data permission architecture and system functions. Developers or other relevant personnel do not need to have an in-depth understanding of the specific functional points of the system, but only need to focus on configuring the data permission architecture. For example, for the "employee information table" in the database, configuration personnel can directly set the permissions of different user roles for query, insert, update and delete operations on the table according to business needs, without having to consider which specific functional modules these operations correspond to in the system. This decoupling method makes the permission configuration work more concise and efficient, reducing the configuration difficulty and error risk caused by functional complexity.

[0092] 3.3 Adaptability to projects at different development stages

[0093] This feature of the present invention enables data permission configuration to be completed quickly, regardless of whether the project is under development or has been completed. For projects under development, developers can configure the data permission architecture simultaneously with the design of the data model, integrating permission management into the project development process to avoid rework caused by permission configuration issues in the later stage. For projects that have been completed, since the permission configuration is decoupled from the system function, there is no need to make large-scale modifications to the original functional code. It only needs to be configured according to the requirements of the data permission architecture to quickly achieve data permission management and control. This flexibility and adaptability greatly improves the maintainability and scalability of the project, and reduces the cost and time investment of enterprises in data security management.

[0094] In summary, the present invention achieves the separation of permission configuration and system functions by performing permission management oriented to the data model, and provides an efficient, flexible and easy-to-implement data permission management solution for projects at different development stages.

[0095] Glossary:

[0096] ORM framework: The ORM (Object Relational Mapping) framework is a programming technology that builds a bridge between object-oriented programming languages (such as Python, Java, C#, etc.) and relational databases (such as MySQL, Oracle, SQLServer, etc.), allowing developers to use an object-oriented approach to operate the database without having to directly write complex SQL statements. The core idea of the ORM framework is to map the tables in the database to classes in the program, the records in the tables to objects of the class, and the fields in the tables to the properties of the objects. Through this mapping relationship, developers can use the methods and properties of the objects to perform database addition, deletion, modification, and query operations. The ORM framework will automatically convert these operations into corresponding SQL statements and execute them.

[0097] Front-end and back-end alignment: In software development, the front-end is primarily responsible for the user interface, including page design, layout, visual effects, and responses to user actions. The back-end focuses on processing business logic, data storage and management, and database interaction. Front-end and back-end alignment ensures that the content and interaction logic displayed on the front-end work seamlessly with the data and business logic provided by the back-end. For example, when a button is clicked on the front-end, the back-end correctly responds and processes the corresponding business operations, returning accurate data for the front-end display.

[0098] Configuration class: It is a program code structure used to centrally manage and configure system parameters, rules and other information. By writing a configuration class, you can control the behavior of the server more flexibly and finely.

[0099] Table pass module: In database permission management or data access control scenarios, the "table pass module" is a functional module used to handle permission transfer or access control for table data. Its core function is to intercept database query operations (such as SQL statements) and, based on pre-set permission rules, determine whether to allow users or applications to access specific table data. It then completes the data transfer when the conditions are met. BRIEF DESCRIPTION OF THE DRAWINGS

[0100] Figure 1 This is a schematic diagram of the structure of the data authority control system of the present invention;

[0101] Figure 2 A schematic diagram of a flow chart of an embodiment of the present invention;

[0102] Figure 3 This is a schematic diagram of the data structure of the table portion of an embodiment of the present invention, which is used to represent the data structure of the table portion after the permission controller splits the SQL, and is subsequently used by the data permission management server to identify the table permission hit table;

[0103] Figure 4 This is a schematic diagram of the data structure of the conditional part of an embodiment of the present invention, which is used to represent the data structure of the conditional part after the permission controller splits the SQL. It is subsequently used for the data permission management server to quickly add dimension conditions and reorganize the permission controller.

[0104] Figure 5 This is a schematic diagram of Clause SQL conversion according to an embodiment of the present invention, used to illustrate the transformation process of the clause strength set by table pass on the original SQL;

[0105] Figure 6 This is a schematic diagram of the Condition SQL conversion in an embodiment of the present invention, used to express the process of transforming the condition strength set by the table pass to the condition in the original SQL;

[0106] Figure 7 This is a schematic diagram of the dimension SQL conversion of the data authority management server in an embodiment of the present invention, which is used to express the process of converting the permission dimension configured by the data authority management server to the original SQL table;

[0107] Figure 8 This is a schematic diagram of the data structure after the SQL statement is split in an embodiment of the present invention. DETAILED DESCRIPTION

[0108] like Figure 1 As shown, a data permission control system based on low decoupling of data entities includes a data permission management server and several permission controllers. The data permission management server and the permission controllers exchange data via a data transmission unit, which typically transmits data over a wide area network. This means that the data permission management server and the business system with the permission controller can be located in different locations. An implementation example is provided in the Springboot framework under the JavaWeb system to establish a data permission control system based on low coupling of data entities, as follows:

[0109] 1. Data rights management server

[0110] 1.1 Application Configuration Unit

[0111] This is a pre-operation for data permissions, which aims to lay the foundation for subsequent processing of data permission entities and SQL operations. It is performed in the application configuration unit of the data permission management server.

[0112] 1.1.1APP configuration module (application configuration service)

[0113] App configuration is one of the core functions of the application configuration unit. Within the distributed service architecture, the App Configuration module's Application Configuration Service, as a foundational support component, assumes the core responsibility of application metadata management. This service utilizes an independently deployed technical architecture, decoupled from business systems through loosely coupled design principles, and positioned as a standardized configuration service hub. As a typical support service, the Application Configuration Service primarily provides basic configuration capabilities for various business systems. Its service lifecycle operates independently of the business systems and is elastically scalable based solely on the actual needs of the business systems.

[0114] The core configuration elements of this service include but are not limited to the following technical parameters:

[0115] Application identification information: including basic metadata such as application name and application unique identifier (APP ID);

[0116] Service contact information: including technical person in charge, contact number and other operation and maintenance related information;

[0117] Security authentication parameters: mainly the key system required for communication between services.

[0118] When a business system requires integrated data rights management, system administrators must configure it through the data rights management platform. These configuration parameters primarily serve to achieve logical isolation between services. By establishing unified configuration standards, these parameters ensure that different business systems share basic service resources while effectively safeguarding data security and service boundaries. This centralized management model provides a standardized solution for resource management in a multi-tenant architecture.

[0119] 1.1.2 Dimension Configuration Module

[0120] In the data rights management system of this embodiment, dimensions are defined as logical units for implementing fine-grained rights control. This model adopts a hierarchical rights control strategy and constructs a multi-dimensional rights control matrix through a dimension configuration mechanism. The specific implementation logic is as follows:

[0121] 1.1.2.1 Dimension Control Logic

[0122] Using a permission control model that superimposes orthogonal dimensions, when configuring a specific dimension, the system only implements access restrictions on data within that dimension, while data in other dimensions retains its original permission rules. If multiple dimensions are configured simultaneously (such as Dimension A and Dimension B), the system automatically generates permission constraints in the form of a Cartesian product, forming a joint control mechanism for the composite dimensions.

[0123] 1.1.2.2 Core Configuration Elements - Dimension Metadata

[0124] Dimension identification: Use naming conventions that are completely consistent with the database physical table structure to ensure system-level unique identification;

[0125] Dimension name: a readable identifier for business scenarios;

[0126] Dimension field: points to a specific field in the database table and serves as the physical carrier for permission matching;

[0127] 1.1.2.3 Data Mapping Mechanism

[0128] The system implements dynamic binding of permission rules by establishing a mapping relationship between dimension fields and physical table fields. This mapping relationship must meet the following technical requirements:

[0129] Field-level exact matching: ensures that the type and length of dimension fields are exactly the same as those of database table fields;

[0130] Cross-database consistency: supports field mapping synchronization in distributed database environments;

[0131] Version management: provides historical traceability of configuration changes;

[0132] 1.1.2.4 Control Mechanism Characteristics

[0133] This configuration system uses a dimension-based logical isolation mechanism and establishes a dimension-field-permission triple mapping relationship to achieve the following core functions:

[0134] Permission inheritance control: supports permission inheritance and overwriting rule configuration between dimensions;

[0135] Dynamic permission calculation: Permission determination is performed based on a combination of dimensions in real-time context;

[0136] Multi-tenant support: resource sharing and security control are achieved through dimension-level tenant isolation;

[0137] This configuration system serves as the foundational architecture for the data rights management system, providing a standardized data model for subsequent rights policy development, access control implementation, and audit tracking. Specific application scenarios and implementation details will be described in detail later.

[0138] 1.1.3 Data Entity Configuration Module

[0139] In a data rights management system, data entity configuration serves as a core control node, playing a key role in establishing data access boundaries. This configuration system establishes a mapping relationship between data entities and rights control rules to achieve precise control over business system data operations. Its technical implementation mechanism is as follows:

[0140] 1.1.3.1 Core Function Positioning

[0141] Data entity configuration adopts a declarative configuration model, which forms a unified permission control benchmark by defining the binding relationship between data entities and control rules;

[0142] After the configuration takes effect, all business operations involving the data entity (including but not limited to CRUD operations) must follow the configuration rules unless overridden by an exception policy;

[0143] 1.1.3.2 Configuration Elements Analysis

[0144] Data entity metadata

[0145] Data entity table: points to the specific table structure in the physical database and must include the complete database / table name identifier;

[0146] Dimension combination: Based on the dimension management system described in Section 1.2, it supports multi-dimensional combination configuration;

[0147] Control expression: a conditional expression consisting of comparison operators (greater than, greater than or equal to, less than, less than or equal to, equal to) and dimension field values;

[0148] 1.1.3.3 Control Mechanism Implementation

[0149] 1.1.3.3.1 Rule Binding Strategy

[0150] Global effectiveness principle: Configuration rules are effective for all operations on data entity tables by default;

[0151] Exception priority: supports business systems to override global rules through local configuration, forming a conflict resolution mechanism;

[0152] Version management: provides historical version tracing and rollback capabilities for configuration rules;

[0153] 1.1.3.3.2 Data Mapping Mechanism

[0154] Field-level binding: dimension fields in control expressions must be accurately mapped to database table fields;

[0155] Cross-database consistency: supports data entity configuration synchronization in distributed database environments;

[0156] Dynamic loading: Configuration rule changes take effect in real time without restarting the business system;

[0157] 1.1.3.4 System Architecture Value

[0158] Permission consistency guarantee: Through unified data entity configuration, ensure that the access rights of multiple business systems to the same data are standardized;

[0159] Fine-grained control: Supports field-level data access control to meet the differentiated needs of different business scenarios;

[0160] Operation and maintenance convenience: Provides a visual configuration interface and automated verification mechanism to reduce configuration error rates;

[0161] This configuration system serves as the basic framework for data rights management and works in conjunction with modules such as dimension management and policy engine to build a complete data security protection system. Specific exception configuration rules and conflict resolution strategies will be described in detail later. 1.2 Data Entity Unit

[0162] This unit mainly handles table lists, storage and filtering operations, as well as the storage and processing generation of SQL conditions. Its sub-modules include table processing module and SQL condition processing module.

[0163] 1.2.1 Table Processing Module

[0164] In the data rights management system, the table routing and condition generation module serves as the core processing unit, responsible for the dynamic routing of business system table information and the injection of SQL conditionals. This module utilizes a layered processing architecture, establishing a three-level processing pipeline consisting of table information temporary storage, screening and matching, and condition generation to achieve precise control of data access. Its technical implementation mechanism is as follows:

[0165] 1.2.1.1 Module Architecture Positioning

[0166] As the pre-processing node of the data rights management system, it is responsible for receiving table metadata information transmitted by the business system. It uses an asynchronous processing mode to support temporary storage and rapid retrieval of table information in high-concurrency scenarios. It forms a closed-loop control with the 1.1.3 Data Entity Configuration Module to achieve dynamic loading and real-time effectiveness of configuration rules.

[0167] 1.2.1.2 Core Processing Flow

[0168] 1. Table information temporary storage mechanism

[0169] oEstablish a temporary storage queue to perform structured storage of metadata such as table names, field information, and operation types passed in by the business system;

[0170] oSupports adaptation and conversion of multiple source data formats, including but not limited to serialization protocols such as JSON and XML;

[0171] oImplement version management of table information and record the context information of each operation;

[0172] 2. Table screening processing logic

[0173] oBuild a table routing policy engine that supports multiple filtering algorithms based on regular expressions, pattern matching, etc.

[0174] oExecute multi-level filtering rules: first perform global table matching, then apply business system specific rules, and finally perform field-level filtering;

[0175] oImplement priority sorting of hit lists and support dynamic adjustment of weighted algorithms;

[0176] 3. Condition generation mechanism

[0177] oBuild SQL condition generator based on control relations (such as greater than, equal to, etc.) configured in module 1.1.3

[0178] Generate standard WHERE clause;

[0179] o Using template generation technology to support adaptation and conversion of different database dialects (such as MySQL, Oracle, etc.);

[0180] oImplements combination operations of conditional expressions, supports AND / OR logical combination and bracket priority control;

[0181] 1.2.1.3 Key Points of Technical Implementation

[0182] 1. Dynamic conditional injection

[0183] oUse AST (Abstract Syntax Tree) parsing technology to achieve safe injection of SQL statements;

[0184] oSupport conditional parameter binding for prepared statements to prevent SQL injection attacks;

[0185] oProvide a visual debugging tool for conditional expressions and support real-time preview of generated results;

[0186] 2. Data consistency assurance

[0187] oEstablish a table information verification mechanism to ensure the consistency of the incoming table structure and data entity configuration;

[0188] oAchieve dynamic synchronization of cross-library table structures and support configuration consistency in distributed database environments;

[0189] oProvide condition conflict detection function to automatically identify and prompt conflicting permission rules;

[0190] 3. Performance Optimization Strategy

[0191] oUse the LRU cache strategy to cache and accelerate frequently accessed table information;

[0192] oImplement asynchronous processing and decouple the business system from the authority control system through message queues;

[0193] oSupports horizontal expansion architecture and achieves linear growth of processing capacity through load balancing;

[0194] This module serves as the execution center of the data permissions management system. By integrating table routing with conditional generation, it achieves automated and intelligent data access control. Its processing results are directly passed to the SQL execution engine for final data operation permission verification. Specific policy configuration methods and performance optimization parameters will be detailed later.

[0195] 1.2.1.1 Table Screening

[0196] In the data rights management system, the table routing and filtering module serves as a pre-processing node for data access control, fulfilling the core function of intelligently routing and matching permissions rules for the business system's SQL metadata. This module utilizes a table metadata filtering mechanism based on a rules engine. By establishing a three-level processing system consisting of table list verification, rule matching, and dynamic routing, it achieves precise and efficient data rights control. Its technical implementation mechanism is as follows:

[0197] 1. Module architecture positioning

[0198] As the interaction hub between the business system and the rights management system, it is responsible for receiving and parsing the table metadata collection transmitted by the business system. It adopts an asynchronous transmission mechanism to support batch processing of table information in high-concurrency scenarios, and forms a strategic linkage with the 1.1.3 data entity configuration module to realize dynamic loading and real-time verification of configuration rules.

[0199] 2. Core processing flow

[0200] 1) Table metadata reception

[0201] Establish a standardized data interface to support parsing and conversion of multi-format table lists (such as JSON / XML protocols), implement data integrity verification to ensure the accuracy of metadata such as table names, field information, and operation types, and adopt a versioning management mechanism to record the context information of each table list transmission;

[0202] 2) Routing filtering rules

[0203] Build a multi-level matching strategy: first perform global table rule matching, then execute business system-specific rules, and finally perform field-level filtering. Support a variety of algorithm combinations such as regular expressions, fuzzy matching, and exact matching to implement table priority sorting and dynamically adjust the screening results based on weight coefficients;

[0204] 3) Generation of permission list

[0205] The rule engine performs two-way verification with the table entities configured in module 1.1.3, generating a table list containing complete permission control information, including database / table names, dimension combinations, control expressions, and other elements. A change notification mechanism is implemented to provide real-time feedback of screening results to the business system.

[0206] 3. Key points of technical implementation

[0207] 1) Intelligent routing algorithm

[0208] Adopting AST-based SQL semantic analysis technology, it implements intelligent parsing of table aliases, supports cross-database table routing, implements table mapping management of distributed databases through the configuration center, establishes a table caching mechanism, and preloads frequently accessed table information.

[0209] 2) Data consistency assurance

[0210] Implement table structure verification to ensure field-level consistency between the incoming table and the configuration table. Provide conflict detection to automatically identify duplicate or contradictory table configuration rules. Support configuration version rollback to ensure traceability of system changes.

[0211] 3) Performance optimization strategy

[0212] It adopts a parallel processing architecture, improves table screening efficiency through multi-threading technology, implements asynchronous processing, decouples business systems and permission systems through message queues, provides horizontal scalability, and supports linear throughput growth through load balancing.

[0213] As a core component of the data permissions management system, this screening mechanism establishes an intelligent mapping between table lists and configuration rules, providing a precise input foundation for subsequent SQL condition generation and permission control. The processing results are directly passed to the dimension permission processing unit to complete the final data access control logic. Specific policy configuration methods and performance tuning parameters will be explained in detail later.

[0214] 1.2.1.2Table pass filtering

[0215] In this embodiment's data permission management and SQL execution optimization system, the 2.2.2 table pass module plays a key role in table screening intervention. During business system operation, some scenarios require differentiated control of SQL hit tables. This means that even though certain tables are hit during SQL parsing, new SQL conditions do not need to be generated based on conventional logic. To meet this requirement, the table processing module and the table pass module establish a two-way information exchange mechanism.

[0216] In the data permission control standard process of this embodiment, before executing the 1.2.1.1 table screening link, the system will give priority to judging the configuration of the table pass module. If the module has not made any settings, the table processing module will maintain the table list as it is and will not perform any intervention operations. If the table pass module is configured with specific filtering rules, the table processing module will perform filtering operations on the input table list according to the established rules. Specifically, the table processing module will remove the tables specified in the table pass module from the table list. Through this operation, it is ensured that the final output table list does not contain the tables set by the table pass module, thereby achieving precise intervention in the subsequent SQL condition generation and data access control process.

[0217] 1.2.2SQL Condition Processing Module

[0218] In this embodiment of the data rights management system, the SQL condition management module, a key component, performs the dual functions of temporarily storing SQL condition information and providing a method for generating it. During operation, the business system transmits relevant information about the SQL condition to this module, which then temporarily stores this information in a structured manner, forming a standardized information repository.

[0219] At the same time, the module has a built-in library of SQL condition generation methods that can be flexibly called. When the dimension permission processing unit generates new SQL conditions based on the rules set by the 1.1.3 data entity configuration module, it can easily obtain the required generation methods from this module. These methods are designed to fully consider the differentiated needs of different business scenarios for SQL conditions, as well as the differences in syntax and characteristics of various databases, to help the dimension permission processing unit quickly and accurately generate SQL conditions that meet business logic and data permission requirements, and effectively ensure the security and accuracy of the data permission management system during data query and operation.

[0220] 1.3 Dimensional Permission Processing Unit

[0221] In the architecture of the data rights management system, the dimension rights processing unit serves as a communication and condition generation coordination unit, building a bridge between the business system and the rights management system, and undertakes multiple core functions.

[0222] This unit has established standardized communication interfaces to ensure stable and efficient data interaction with business systems. Compatible with multiple mainstream communication protocols, it meets the real-time and reliable data transmission requirements of various business scenarios. Furthermore, through a built-in application authentication mechanism, access requests initiated by business systems are rigorously authenticated and permission-verified, ensuring the security and legitimacy of interactions between systems.

[0223] Furthermore, this unit serves as a central coordination hub for generating new SQL conditions, linking multiple key modules within the system to efficiently generate SQL conditions that meet business logic and security requirements based on established data permission rules. Furthermore, this unit is responsible for cache notifications, monitoring data changes in real time and sending timely cache update notifications to relevant modules to ensure cached data consistency, thereby optimizing overall system performance, effectively reducing data access latency, and improving system responsiveness.

[0224] 1.3.1 Business System Communication Interface

[0225] As the core module of the data permission management system, the dimension permission processing unit provides the business system with three types of communication interfaces with different functions and rigorous design, aiming to ensure the timeliness and accuracy of data permission management and the stability of system operation.

[0226] 1) Version Synchronization Verification Interface: This interface allows business systems to obtain version information for current dimensions and data entities. It then compares the relevant versions within the business system with the corresponding permission versions in the data rights management server to determine whether the two are consistent. This mechanism ensures that business systems always use the version that matches the current permission configuration, avoiding data access anomalies caused by version inconsistencies.

[0227] 2) Dynamic SQL Condition Generation Interface: When a business system detects a discrepancy between its current dimension and data entity versions and those in the data rights management server, the cached SQL conditions may become invalid. In this case, the business system can use this interface to request the dimension rights processing unit to retrieve SQL conditions that conform to the latest rights configuration, ensuring the security and accuracy of data queries and operations.

[0228] 3) Table hit status determination interface: This interface allows business systems to determine whether a specific table is hit under data permission rules. This interface enables business systems to understand the table's permission status before performing data operations, thereby optimizing data access processes and improving system efficiency.

[0229] These three types of interfaces work together to build a complete dimensional permission interaction system, which not only ensures efficient communication between the business system and the data permission management server, but also provides strong support for the precise control of data permissions and the stable operation of the system.

[0230] 1.3.2 Application Authentication

[0231] In the deployment and operational architecture of a data rights management system, the initial configuration of the App configuration module is a critical prerequisite for enabling data rights management in business systems. Before a business system is officially connected to the data rights management system, the initial configuration of the App configuration module must be completed to provide the core basis for subsequent data access control in the system.

[0232] The system leverages the Dimension Permissions Processing Unit to establish a rigorous two-way authentication mechanism to ensure the security and legitimacy of data interaction. During data interaction, all access requests and data transfers from business systems must proceed through a secure channel verified by this authentication mechanism.

[0233] This two-way authentication mechanism has two core functions. First, it uniquely identifies the application initiating the interaction, ensuring the source and legal identity of the application accessing the system, effectively preventing intrusion and data theft by unauthorized applications. Second, through the pre-set authentication protocol, the system obtains the application's corresponding dimension configuration parameters and data entity configuration rules. This information constitutes the basic data set for data permission verification, providing data support for subsequent accurate and efficient permission verification of business system data access requests, thereby ensuring the normal functioning of the data permission management system and effectively safeguarding the data security of the entire system.

[0234] 1.3.3 Coordinate the generation of new SQL conditions

[0235] Within the operational framework of the data rights management system, the new SQL condition generation module collaborates with the 1.2.1 Table Processing Module and the 1.2.2 SQL Condition Processing Module to establish a complete and efficient SQL condition generation mechanism. The business system transmits the table list and SQL conditions to the table processing module and the SQL condition processing module through established communication interfaces, and the system stores this data persistently.

[0236] The table processing module then filters the table list according to pre-set rules to generate a final list of hit tables. Based on this, and in conjunction with the configurations set in the data entity configuration module in 1.1.3, each module collaborates to generate dimensional SQL conditions.

[0237] In the system, each targeted data entity supports data permission control via single or multiple dimensions. Based on the current user dimension node identified in Section 2.3.1, the system performs a splicing operation on the SQL conditional portion. Simultaneously, the data entity permissions set in the data permission management server are combined according to specific rules to form a new SQL statement, which is then added to the conditional set.

[0238] In the data return phase, the data rights management server sends the generated new SQL back to the business system for the business system to integrate the new SQL. The integration process uses "AND" as the control keyword to implement the intersection operation of the data rights of each dimension, thereby obtaining a data set that meets the permission requirements. For detailed execution logic and application examples of this mechanism, please refer to Figure 7 The content shown.

[0239] 1.3.4 Cache Mechanism (Data Rights Management Server)

[0240] During the operation of the data rights management system, when SQL conditions are successfully generated based on table information and the current user dimension node, the system uses the table, current user dimension node, and appID as indexes, applies a UUID algorithm to generate a unique version number, and stores it in a system-specific data structure. The generated version number, along with the newly generated SQL conditions, is fed back to the business system as a response.

[0241] If the business system subsequently initiates a new SQL condition generation request based on the same table and current user dimension node, the system will prioritize the index as the retrieval basis and perform the query operation in the cache. If a matching record is successfully found in the cache, and the record completely matches the relevant configuration information in the data permission management server, the business system will directly call the SQL condition in the cache to improve data processing efficiency and reduce system resource consumption. If the cache query does not hit, or there is a difference between the cache record and the data permission management server configuration information, the business system will trigger the data permission management server and re-execute the SQL condition generation process to ensure that the obtained SQL condition meets the latest data permission configuration requirements.

[0242] 2. Injection of permission controller (business system side)

[0243] When building a business system that relies on a data permission service, implementing specific technical integration steps is essential. For example, using the Spring Boot framework, widely used in Java Web development, the project's pom.xml file must include dependencies for the data permission controller. These components, leveraging Spring Boot's auto-configuration and dependency injection mechanisms, are deeply integrated into the business system's data access chain, implementing a series of core functions. At the SQL level, they intercept SQL statements using AOP (Aspect-Oriented Programming) technology for real-time monitoring and analysis of data access requests. Regarding permissions management, they precisely control data access granularity based on pre-defined permission models, ensuring that users can only access authorized data. At the system interaction level, they provide secure and efficient communication interfaces with the data permission service, enabling dynamic updates and synchronization of permission policies. Furthermore, they provide on / off control, allowing developers and operations personnel to flexibly enable or disable data permission control based on business needs and system status, providing strong support for stable system operation and flexible business expansion.

[0244] 2.1 Business System Configuration Unit

[0245] After the business system completes the integration of the permission controller component, it must conduct comprehensive and detailed basic configuration work with the help of the business system configuration unit. This process uses standardized configuration processes to deeply adapt the business system and the permission controller component, clarifying key configuration parameters such as data access paths, permission verification rules, and inter-system interaction logic. This ensures that the permission controller component can operate stably in the business system, thereby providing effective and accurate permission control for data access. This basic configuration process is not only a necessary prerequisite for the smooth operation of the system, but also lays a solid foundation for the subsequent flexible adjustment of permission strategies based on business development.

[0246] 2.1.1 Identity Setting Module

[0247] When building a data permission control system, whether using role-based, attribute-based, or other complex control strategies, accurately obtaining the current user's identity information is an indispensable core link. This identity information serves as the key basis for data permission control and is used to accurately locate the user's position in the dimension configuration system defined in Section 1.2. Taking the organizational dimension as an example, when the system sets the permission for users in upper-level organizations to view data in lower-level organizations, the system needs to use the user's position information in the organizational tree structure to achieve refined control over access rights to specific data. To achieve this function, the business system needs to rely on the identity setting module to obtain the identity context information of the current thread.

[0248] At the implementation level, the business system must specify the path to the identity acquisition method in the configuration file, such as com.xxx.handle.method. When the permission controller initiates a request to obtain user identity information, the system instantiates the corresponding class based on this path and retrieves the user's identity information by calling the preset method in the class. The obtained identity information not only includes the user's basic identification but, more importantly, covers the user's node information in various configuration dimensions, providing comprehensive and accurate data support for the system's implementation of data permission control, ensuring the security and compliance of data access.

[0249] 2.1.2 Communication Settings Module

[0250] Given that the data rights management system utilizes a service-oriented architecture, integrating business systems into the system requires a rigorous configuration process to ensure secure and accurate inter-system communication. Business systems must configure communication parameters, a process that essentially serves as an authentication mechanism. They also require a unique identifier for the service business system. This identifier must be set according to the app configuration specifications described in Section 1.1.1.

[0251] Specifically, the core parameters that need to be configured in the business system are as follows:

[0252] Host: This parameter specifies the access address of the data rights management service to ensure that the business system can accurately connect to the data rights management service.

[0253] APPID and APPSECRET: These two parameters are key authentication information generated according to the app configuration process in Section 1.1.1. The APPID uniquely identifies the business system and is used to distinguish different business systems within the data rights management system. APPSECRET, used in conjunction with the APPID, serves as the authentication key to ensure secure communication between the business system and the data rights management system, preventing unauthorized access and data leakage.

[0254] By completing the above parameter configuration, the business system can smoothly access the data rights management service and realize the effective management and control of data rights.

[0255] 2.1.3 Cache settings module

[0256] This embodiment uses third-party cache systems such as Redis and MongoDB. When integrating a third-party cache, you need to instantiate the corresponding cache connection based on the name of the cache service. To do this, you need to complete a series of standardized configuration tasks:

[0257] 2.1.3.1server: Used to specify the cache service type used, such as Redis or MongoDB, to clarify the cache technology framework used by the system.

[0258] 2.1.3.2host: The IP address of the server where the cache service is located needs to be configured to ensure that the system can accurately establish a network connection with the cache service.

[0259] 2.1.3.3port: corresponds to the port number that the cache service listens on, and works together with the IP address to accurately locate the network location of the cache service.

[0260] 2.1.3.4password: For security reasons, configure the password required to access the cache service to prevent unauthorized access and ensure the security of cached data.

[0261] 2.1.3.5database: Specifies the specific database within the cache service to facilitate the system's classification and management of cached data and improve data access efficiency.

[0262] As a core element to improve system performance, the cache mechanism plays a key role in optimizing data access speed and reducing the pressure on the back-end database.

[0263] 2.2 Custom Control Unit

[0264] The custom control unit effectively provides a "force control mechanism." In this embodiment, the force control mechanism is designed to accurately respond to diverse business needs and meet the demands for personalized configuration of data permissions during the development process. Typically, data permissions configured by the system based on established rules can cover the vast majority of business functional scenarios and provide a foundational security guarantee for data access.

[0265] However, given the complexity and diversity of business logic, generic data permission configurations can't meet differentiated control requirements in certain functional modules or business scenarios. In these situations, the system leverages custom control units to implement refined data access control through a force control mechanism. Developers can flexibly adjust the granularity of data permissions based on specific business logic, achieving precise control over data access and ensuring that the data permission management system both ensures data security and adapts to complex and ever-changing business needs.

[0266] 2.2.1 Permission Control Switch

[0267] In data permission control development projects built on a service-oriented architecture, considering the diversity of business scenarios, some scenarios do not require data permission control. Given that the system adopts a global control mode for data permission entities, the permission controller has designed a flexible switch configuration mechanism for individual SQL statements.

[0268] During business execution, a single scenario often involves multiple SQL queries. When a data query fails to retrieve required data due to missing permissions, developers can use permission controls to adjust the permission control policy for a specific SQL statement. By default, the permission controller intercepts all SQL queries. To bypass permission control for a specific SQL statement, developers can add the ThreadlocalSql.pass(true) directive before executing the SQL statement in code, allowing the permission controller to pass the SQL statement. After the SQL statement is executed, to prevent it from impacting subsequent SQL queries, the configuration must be restored to ThreadlocalSql.pass(false).

[0269] Furthermore, when processing complex SQL queries, especially those involving multi-table joins, the Permission Controller provides a single-table data permission control feature to meet the need for refined permission control for specific tables. This feature allows developers to independently configure permission control rules for specific tables, significantly improving the flexibility and precision of permission control and ensuring the efficient and stable operation of the data permission management system in complex business scenarios.

[0270] 2.2.2table pass module

[0271] In data permission management scenarios, when permission controls are set on data entity tables, data access paths are often restricted when performing table-join queries. To effectively address this challenge, this control unit provides a targeted solution.

[0272] When using this unit, developers must configure it in their code before executing SQL. This configuration must adhere to the principle of uniqueness, ensuring that table names are unique. The specific configuration command is ThreadlocalSql.tablePass("tablename","off") This command intervenes in the permission verification process for a specific table through the pre-defined permission control mechanism.

[0273] When the SQL execution process ends, the controller automatically triggers a cleanup mechanism to clear all configuration information related to this operation. This design not only avoids redundant configuration information accumulation and reduces potential risks caused by residual configuration, but also ensures that subsequent SQL operations are not affected by the current configuration, maintains the independence and stability of the system's permission control logic, and ensures that data query operations are carried out in an orderly manner within the established permission framework.

[0274] 2.2.3 Custom Dimension Module

[0275] This unit builds on the existing framework for data permission control to create a convenient and efficient SQL query enhancement mechanism for developers, helping them achieve refined data retrieval. When performing data queries, developers can use this unit to introduce new dimension control logic to existing SQL queries and flexibly select OR or AND operation strength to further enrich query condition combinations.

[0276] For example, when developers need to query user organization dimension data, they can enable custom dimension processing to query the user's current organization and the data they have previously created within that organization. To implement this, developers need to call the custom dimension component in the controller before executing SQL. This is done by executing the ThreadlocalSql.customizeLevel("tablename","column","operator","value","rel") code to customize the query conditions.

[0277] Among them, "tablename" specifies the target table name; "column" specifies the table field to be operated; "operator" provides a variety of comparison operators, including greater than, greater than or equal to, etc., to meet different condition judgment requirements; "value" sets the query matching value; "rel" determines the logical relationship between the new condition and the original SQL, "condition_OR" and "condition_AND" are used to integrate control logic at the condition level, and "clause_OR" and "clause_AND" play a role at the WHERE clause level.

[0278] To prevent configuration residues from interfering with subsequent SQL operations, the system will automatically clear all custom settings involved in each SQL operation after each SQL execution, ensuring a clean system operating environment and maintaining the independence of the permission control logic between SQL operations.

[0279] 2.2.3.1 rel is the strength of the clause

[0280] When the rel parameter configured in Section 2.2.3 of this embodiment is set to the clause strength, and the corresponding table is hit during the parsing of the original SQL, the system will trigger a specific processing mechanism. Under this mechanism, the splicing rules of the original SQL conditions and the newly added dimension conditions are as follows: splicing is performed in the format of (original SQL) clause or / and newly added dimension conditions. This splicing strategy is consistent with the conditional splicing specifications specified in Section 2.3.1.3, and a conditional linked list is constructed in this way. For the operational process and effect display of this splicing mechanism in actual application, please refer to Figure 5 The specific example shown. With this splicing logic, the system can flexibly integrate the original SQL query logic with the newly added dimension control conditions, ensuring that data queries comply with established permission rules while meeting complex and changing business needs, further improving the accuracy and flexibility of data retrieval. 2.2.3.2 rel is the strength of condition

[0281] When the rel parameter is specified as the condition strength according to the configuration set in Section 2.2.3, if the system not only hits the relevant table but also hits the specific field in the SQL conditional statement during the parsing of the original SQL, the system will automatically trigger the corresponding processing mechanism. Under this mechanism, the SQL conditions hit in the original SQL and the newly added dimension conditions are spliced in the form of (original SQL) condition or / and newly added dimension conditions. This splicing rule is consistent with the specifications for SQL condition splicing in Section 2.3.1.2. Through orderly splicing, a set of logically coherent conditional linked lists is constructed. This process realizes the organic integration of the original SQL logic and the newly added dimension control, which not only maintains the consistency of SQL execution, but also further enhances the accuracy and flexibility of data queries. If you want to intuitively understand the specific application scenarios and execution effects of this splicing mechanism, please refer to Figure 6 Detailed example shown.

[0282] 2.3SQL Interception Unit

[0283] SQL interception, as a core component of the data permission control system, plays a key role in ensuring the security and compliance of data access. In the current industry environment, different object-relational mapping (ORM) frameworks use different SQL interception mechanisms based on their own architectural characteristics.

[0284] This section systematically explains the entire SQL processing lifecycle, covering all operational processes from SQL interception to data result processing and communication with the data permissions service. It also provides an in-depth analysis of the application scenarios and usage methods of each of the previously described configurations. By combining theoretical explanations with practical examples, it details key parameter configurations, operational steps, and precautions, providing a comprehensive overview of how to effectively utilize SQL interception technology to build an efficient and secure data permissions management system.

[0285] 2.3.1 Disassembling the original SQL

[0286] When a thread enters the program to execute a query SQL operation, the permission controller will initiate an interception and parsing mechanism before the SQL is executed. Query SQL typically contains one or more SELECT clauses, often with complex nested clauses. For example, the query "SELECT customer_name FROM customers WHERE customer_id IN(SELECT customer_id FROM orders WHERE amount > (SELECTAVG(amount) FROM orders))" contains two SELECT clauses: one of which constitutes the main query statement, and the other is embedded within the main statement as a query condition.

[0287] To achieve efficient SQL splitting and reorganization, the system adopts a specific data deconstruction strategy. The deconstructed data structure consists of five parts: magic SQL, location index, table list, conditions, and sub-objects. Each part has a unique function and works together to complete the structured storage and management of SQL information. The relevant data structure organization can be referred to Figure 8 With this design, the system not only improves SQL processing efficiency, but also provides strong support for subsequent operations such as permission control and query optimization based on SQL data deconstruction.

[0288] 2.3.1.1 Table Partial Analysis

[0289] In the SQL query syntax, the table-related components primarily encompass two main sections: FROM and JOIN. When designing data query results, query tables carry two key attributes: table name and alias. The table name serves as the inherent identifier of a table in the database. The database system uses this name to accurately locate a specific table and execute data queries. The alias, on the other hand, is a temporary identifier assigned to a table by an SQL query statement. It is used to clearly distinguish fields corresponding to different tables within query conditions and field definitions, avoiding field confusion caused by duplicate table names or complex structures.

[0290] Taking actual application scenarios as an example, with the help of typical SQL query statements, we can clearly demonstrate the role and usage of table names and aliases in the query process. For specific examples, please refer to Figure 3 Through Figure 3 The analysis of the case can provide an in-depth understanding of the positioning and function of table names and aliases in SQL query statements, which helps to build more standardized and efficient SQL query logic.

[0291] 2.3.1.2 Conditional Part Analysis

[0292] In the SQL query logic system, the conditional part is the core module that determines the data filtering scope and result accuracy. Its data structure design has a profound impact on system performance and query efficiency. The data structure of the conditional part consists of the table alias, field, operation operator, value, group identifier, connector (AND / OR), and next node identifier.

[0293] In practical applications, single conditions are expressed in a standardized manner through this data interface, while multiple conditions are linked in an orderly manner using a linked list structure. This linked list design greatly improves the efficiency of modifying intermediate nodes, ensuring that the system can maintain efficient and stable operation even when dealing with complex condition combination changes.

[0294] The following is a detailed explanation of each attribute in the data structure:

[0295] 1) Node Identification: Use randomly generated UUID characters to give each conditional node a unique identity, effectively avoiding node conflicts and ensuring that the system can accurately identify and locate each node in complex conditional networks.

[0296] 2) Table aliases, fields, operators, and values: The definition and use of these attributes follow industry standards, ensuring the standardization and universality of SQL statements and reducing development and maintenance costs.

[0297] 3) Group ID: This accurately indicates the opening and closing status of brackets. It contains two sub-attributes: the number of bracket openings and the number of bracket closings. The former records the number of bracket openings before the condition, while the latter reflects the number of bracket closings after the condition. For example, in the conditional statement "(columnA=aAND columnB=b))", the group ID for the "columnA=a" condition has a number of openings of 1 and a number of closings of 0; in the group ID for the "columnB=b" condition, the number of openings is 0 and the number of closings is 2.

[0298] 4) Connectors: Determine the logical connection between conditions, combine different conditions through "AND" or "OR", and build complex data filtering logic.

[0299] 5) Next Node Identifier: As a key component of the linked list structure, it is responsible for connecting to the next condition entity to form a coherent conditional list. This design significantly improves the integration efficiency of subsequent condition updates, enabling the system to quickly respond to condition changes.

[0300] To more intuitively demonstrate the working principle and application scenarios of the conditional data structure, please refer to the specific examples. Figure 4 Through Figure 4 The analysis can provide a deep understanding of the role and relationship of each attribute in actual SQL queries, and provide a powerful reference for optimizing SQL query logic.

[0301] 2.3.1.3 Magic SQL Explanation

[0302] In this embodiment's SQL processing system, the introduction of the Magic SQL concept aims to significantly improve the efficiency of SQL splitting and reorganization operations. Its core principle is based on the clever use of wildcards in the SELECT clause and conditional parts. For example, when Magic SQL is applied to deconstruct the SQL query "SELECT product_name, price FROM products WHERE price>50," it is transformed into "SELECT product_name, price FROM products WHERE {condition}."

[0303] During this process, the conditional portion of the original SQL statement is extracted and replaced with the placeholder "{condition}." The detailed data structure and organization of the conditional portion are described in Section 2.3.1.2. This design allows the system to quickly locate and extract the conditional portion during the SQL splitting phase; during the reorganization phase, the updated conditional content can also be conveniently embedded into the "{condition}" placeholder of the magic SQL statement. This mechanism greatly simplifies the SQL processing flow, significantly improving the system's responsiveness and processing capabilities when facing complex SQL operations, and providing solid technical support for advanced applications such as data permission control and query optimization.

[0304] 2.3.1.4 Position Indexing, Subobjects, and Disassembly

[0305] When processing complex SQL queries containing nested SELECT clauses, introducing the concepts of positional indexes and sub-objects is an effective solution. Take the SQL statement "SELECT product_id,avg_amount FROM(SELECTproduct_id,AVG(amount)ASavg_amount FROM sales GROUP BY product_id)ASproduct_avg WHERE avg_amount>(SELECT AVG(amount)FROM sales sl where sl.type='online');" as an example. This statement contains three SELECT clauses. To facilitate processing and analysis, we need to split and transform them.

[0306] First, convert the original SQL to "SELECT product_id,avg_amount FROM{select_1}AS

[0307] product_avg WHERE avg_amount>{select_2}", further converted to "SELECT

[0308] product_id,avg_amount FROM(select_1)AS product_avg WHERE{condition}", where "avg_amount>{select_2}" is the condition and the value of the condition part is {select_2}. The condition processing here follows the rules described in Section 2.3.1.2.

[0309] After splitting, the original SQL statement is converted into a root SQL object. The magic SQL for this root object is "SELECT product_id,avg_amount FROM(select_1)AS product_avg WHERE {condition}". The position index is marked as "root". Since this part does not explicitly involve a specific table list, the table list is marked as "null". The condition part is a collection processed according to Section 2.3.1.2. At the same time, the root object contains two sub-objects:

[0310] The first sub-object is derived from "SELECT product_id, AVG(amount) AS avg_amount FROM sales GROUP BY product_id." The magic SQL is the original statement itself, with the position index marked as "select_1." The table list only includes the "sales" table. Because this clause lacks a WHERE condition, permission control only focuses on the dimension permissions of the "sales" table. This sub-object does not contain any child objects.

[0311] The second sub-object comes from "SELECT AVG(amount) FROM sales sl where sl.type = 'online'". The magic SQL is "SELECT AVG(amount) FROM sales sl where {condition}". The position index is marked as "select_2", the table list is also the "sales" table, and the condition "sl.type = 'online'" is processed according to the rules in Section 2.3.1.2.

[0312] Through the above steps, the complex SQL statement containing three SELECT clauses was successfully split and converted. This structured processing method facilitates subsequent SQL operations such as permission control and query optimization.

[0313] 2.3.2 Generate New SQL

[0314] In the data rights management system, after the data rights management server completes the rights calculation, it returns the processed conditions to the business system. Simultaneously, the server uses the user dimension node, table list, and appID as indexes, and a randomly generated version number as the value. This information is stored and fed back to the business system, where it is used for subsequent cache update notifications.

[0315] After receiving the returned content, the business system assembles the SQL statements in sequence according to the dimension conditions. First, the system generates a new SQL statement and then executes it to obtain the required business data set. The SQL reorganization process follows the following method:

[0316] 2.3.2.1 Reorganization of the Main SQL Object

[0317] The permission controller reorganizes the SQL object structure after disassembly in Section 2.3.1.4. First, the SQL object with the position index "root" is processed. The condition part returned by the object is spliced. The specific operation is to traverse the condition list and assemble the individual conditions in sequence according to the rule of "group identifier (open quantity) table alias. Field operation operator value group identifier (closed quantity) connector" to finally form a complete conditional statement. Subsequently, this complete conditional statement replaces the "{condition}" placeholder in the magic SQL.

[0318] 2.3.2.2 Processing of Nested SELECT Sub-Objects

[0319] After completing the splicing of the main SQL, considering that there may be nested SELECT clauses in actual situations, the sub-objects of the main SQL may contain one or more SQL objects. For these sub-objects, the same splicing method as the main SQL is adopted, that is, they are processed according to the rules of Section 2.4.1. After the splicing is completed, according to the position index of the sub-object, its corresponding position in the parent magic SQL is found and replaced. For example, if the parent SQL is "SELECT order_id, customer_id, (select_1) AS order_count FROM orders o", and the position index of the sub-SQL object is "select_1", then the "{select_1}" part in the parent SQL is replaced with the spliced sub-SQL, thus forming a complete new SQL. Finally, the business system executes the new SQL statement to obtain business data.

[0320] Through this structured SQL reorganization method, the system can flexibly handle complex nested queries and ensure that data permission control is effectively applied in SQL queries at all levels.

[0321] 2.4 Cache Mechanism (Business System)

[0322] Based on the cache configuration scheme in Section 2.1.3, to significantly improve overall system performance, a specific caching strategy can be implemented after successfully acquiring the user dimension node, new SQL conditions, and version number. Specifically, the user dimension node, data entity, and appID combination are used as index conditions to cache the version number. Simultaneously, the dimension SQL conditions are cached using the version number as an index. It is worth noting that this version number is also stored on the data rights management server, primarily to provide timely notifications when cached content changes.

[0323] Before the permission controller initiates a request to the data permission management server, it first performs a comprehensive evaluation of the cache. If the cache contains data consisting of relevant dimension nodes and data entities, the business system directly extracts the required SQL dimension conditions from the cache, avoiding unnecessary server requests, effectively reducing system response time, and improving data processing efficiency. This cache-based optimization strategy significantly improves system performance and user experience while ensuring data accuracy and security.

[0324] 2.4.1 Cache Change Notification

[0325] When the system is in a stable operating state, data permissions are generally not updated. However, due to factors such as changes in business needs and security policy adjustments, such updates may still occur. When the data permission management server updates the permissions of a certain dimension of a data entity, it deletes the previously stored version number record corresponding to the table, the current user dimension node, and the appID as the index.

[0326] Before the business system obtains dimension conditions, it initiates a request to the data rights management server to obtain the latest version numbers of the dimensions and data entities. The business system compares the obtained version numbers with the version numbers in the local cache. If the two match, it indicates that the dimension conditions in the cache are up-to-date and valid. The business system will directly obtain the required dimension conditions from the cache to improve data processing efficiency. If the version numbers are inconsistent, it means that the data permissions have been updated and the dimension conditions in the cache may have expired. At this time, the business system will again request the data rights management server to obtain the latest dimension SQL conditions to ensure that data access complies with the latest permission configuration requirements.

[0327] 3. Processing

[0328] After introducing the overall setting and concept of the authority controller in this embodiment, the control flow during the entire use process will be described in detail below to better explain the working principle of the authority controller and the data authority management server. Figures 2 to 8 shown.

[0329] 3.1 Permission Controller

[0330] 3.1.1 Development Phase

[0331] During the Java Spring architecture project development process, the following key configuration steps need to be completed to achieve the integration and customization of the authority controller with the business system:

[0332] 1. Dependency injection: Use Maven's pom.xml file to inject the permission controller into the business system to ensure that the system has the basic ability to control permissions.

[0333] 2. Business system configuration: Within the business system, detailed parameter configuration is performed for different functional modules. Specifically including:

[0334] oCache Settings: Based on the cache settings module in Section 2.1.3, configure the cache strategy and related parameters to optimize system performance and data access efficiency.

[0335] oCommunication Settings: Complete the configuration of communication parameters according to the requirements of the App Configuration Module in Section 1.1.1 and the Communication Settings Module in Section 2.1.2 to ensure stable communication between the business system and the data rights management server.

[0336] oUser identity context acquisition: Configure the method for obtaining the current thread's user identity context through the identity setting module in Section 2.1.1 to provide accurate user identity information for subsequent permission verification.

[0337] 3. Personalized Permission Control: Developers can use the custom control unit in Section 2.2 to customize permission control based on business needs. Specific functional modules include 2.2.1 Permission Control Switch, 2.2.2 Table Pass Module, and 2.2.3 Custom Dimension Module, enabling flexible permission management for specific SQL statements or data operations.

[0338] 3.1.2 Operational Phase

[0339] When the business system thread executes a SQL statement, the SQL interception unit in Section 2.3 will be automatically triggered to intercept and process the SQL statement to be executed. The specific processing flow is as follows:

[0340] ① If the permission control switch in 2.2.1 is set to ThreadlocalSql.pass(true), the SQL statement will execute normally without additional permission processing.

[0341] ② If the permission control switch is not set, the default value is ThreadlocalSql.pass(false). At this time, the SQL statement will enter the subsequent permission processing flow and obtain the table list in the table section of 2.3.1.1.

[0342] ③ Table list parsing: Perform table partial parsing on the SQL statement (2.3.1.1) to obtain the table list involved. In other words, if the table pass module in 2.2.2 is set during the development phase, the table list obtained in 3.1.2 run phase ② is further filtered to obtain a further table list. Otherwise, the table list obtained in 3.1.2 run phase ② is returned.

[0343] ④ Table list filtering: If the 2.2.2 table pass module is set during the development phase, the table list obtained above will be further filtered; if not set, the parsed table list will be directly returned. The specific table hit judgment includes using the table list obtained in 3.1.2 Run Phase ③ and the data set in the 2.1.2 Communication Setting Module as parameters to request the communication interface in 1.3.1 Business System Communication Interface to determine whether a table is hit, and obtaining the result returned by 1.3 Permission Processing Unit whether a table is hit, and then performing corresponding processing based on the returned result:

[0344] 1) If not authorized, the system will report an error and the permission controller cannot be used.

[0345] 2) If no table is hit, the SQL statement is executed normally without any processing.

[0346] 3) If a table is hit:

[0347] a. Use the identity acquisition method set in the identity setting module in 2.1.1 to obtain the identity context of the current user in the business system, which contains the dimension node of the current business system user.

[0348] b. Each select clause is decomposed into five parts (table, condition, magic SQL, position index, child) according to 2.3.1, and the following is obtained: Figure 7 Data of the data structure shown.

[0349] c. Through the hit table returned by the 1.3 dimension permission processing unit, identify the select clause object that needs to update the SQL condition (such as Figure 7 The data structure shown).

[0350] d. Form the tables in the select clause object (2.3.1.1 Table Part Analysis, the table list here is the list after stage ③ of 3.1.2 Operation Phase) and the SQL conditions (2.3.1.2 SQL Condition Part Analysis) into their own data styles.

[0351] e. The rest is used during the SQL reorganization phase.

[0352] f. If the 2.2.3 custom dimension module is set in 3.1.2 operation phase ③, such as ThreadlocalSql.customizeLevel("tablename","column","operator","value","rel")

[0353] g.2.2.3 The custom dimension module will convert it into the following according to the settings: Figure 7 The SQL condition shown in the figure is added to the linked list of the SQL condition part.

[0354] h. Use the identity context obtained in 3.1.2 Operation Phase ④-3)-a and the list of hit tables in 3.1.2 Operation Phase ④-3)-c as parameters to request the user in 1.3.1 Business System Communication Interface to obtain the interface for the current dimension and data entity version and obtain the corresponding version number.

[0355] i. If the version number corresponding to the dimension node and data entity (table) in the response is not empty, then use this version number to obtain the corresponding SQL condition in the cache set by the 2.1.3 cache setting module

[0356] a) If the information returned by the cache is not null, it means that the business system cache has the latest SQL condition. Get the SQL condition object in the cache and add it to the indicated select

[0357] The SQL condition part in the clause object;

[0358] b) If the information returned by the cache is null, it means that there is no latest cache in the business system, and you need to request the data rights management server to obtain new SQL conditions

[0359] j. Use the cache return value of null and the list of tables without a good version as parameters to request the communication interface for generating SQL conditions in 1.3.1 Business System Communication Interface.

[0360] k. After obtaining the data returned by the data rights management server, cache the version number of the index consisting of the appID, the previous user dimension node, and the table, and then cache the returned SQL conditions, as described in 2.4 Caching Mechanism and 2.4.1 Cache Change Notification.

[0361] l. Start SQL reorganization as described in 2.3.2 Generating New SQL.

[0362] m. Execute the new SQL to obtain the data set that the current user can obtain.

[0363] 3.2 Data Rights Management Server

[0364] 3.2.1 Configuration Phase

[0365] During the configuration phase, the data rights management server needs to complete the settings of the application configuration unit to provide basic support for subsequent rights management:

[0366] 1. App configuration: Configure application authorization credentials to ensure that only authorized business systems can communicate and exchange data with the server.

[0367] 2. Dimension configuration: Define the permission control dimensions involved in this application, such as department, organization, etc., to provide a dimensional basis for subsequent permission control.

[0368] 3. Data entity configuration: Configure the data control relationship between business data tables and dimensions, and clarify the access permissions to each data table under different dimensions.

[0369] 3.2.1 Operational phase

[0370] During the operation phase, the data rights management server performs corresponding rights processing and data return according to the business system requests received:

[0371] 3.2.1.1 Table hit determination request processing: After receiving the business system request issued in 3.1.2 Operation Phase ③, perform the following operations:

[0372] oApplication Authentication: Perform application authentication in 1.3.2 based on the information received in 2.1.2 Communication Setup Module to ensure that the request is authorized.

[0373] oUnauthorized: If the authentication fails, the unauthorized information will be returned to the business system.

[0374] Authorized: If authentication succeeds, the 1.3 Dimensional Permission Processing Unit identifies the specific application using the appID in the parameter, compares the data entities (tables) configured in the 1.1.3 Data Entity Configuration Module in the application with the table list in the parameter, identifies the hit table, and returns the result to the business system.

[0375] 2. Version number query request processing: After receiving the business system request from 3.1.2 Operation Phase ④-3)-c, perform the following operations:

[0376] oApplication Authentication: Perform application authentication in 1.3.2 based on the information received in 2.1.2 Communication Setup Module to ensure that the request is authorized.

[0377] oUnauthorized: If the authentication fails, the unauthorized information will be returned to the business system.

[0378] Authorized: If authentication succeeds, the 1.3 Dimension Permission Processing Unit identifies the specific application using the appID in the request parameters, combines the dimensions and table list in the request parameters, and queries the corresponding application. If a version number is found, it is returned to the business system as a response; if not, null is returned.

[0379] 3. Processing of new SQL condition generation request: After receiving the business system request from 3.1.2 Operation Phase ④-3)-j, perform the following operations:

[0380] oApplication Authentication: Perform application authentication in 1.3.2 based on the information received in 2.1.2 Communication Setup Module to ensure that the request is authorized.

[0381] oUnauthorized: If the authentication fails, the unauthorized information will be returned to the business system.

[0382] Authorized: If authentication succeeds, the Dimension Permission Processing Unit (1.3) identifies the specific application using the appID in the parameter. Using the application and the hit table list in the parameter, the Dimension Configuration Module (1.1.2) is used to locate the corresponding information in the Data Entity Configuration Module (1.1.3). Then, based on the current user context in the parameter and the dimension information configured in the Dimension Configuration Module (1.1.2), the corresponding dimension node is retrieved. Combining this information, the system generates new SQL conditions for the corresponding tables and the current user dimension node using the method for generating new SQL conditions in (1.3.3). After generating the SQL conditions, a version number is generated and stored using the caching mechanism (1.3.4). Finally, the newly generated SQL conditions and version number are returned to the business system.

[0383] In summary, the above content is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications made to the present invention by those skilled in the art without departing from the spirit of the present invention shall fall within the scope of protection of the present invention.

Claims

1. A data authority control system based on low decoupling of data entities, characterized in that: It includes a data authority management server and several authority controllers, wherein the data authority management server and the authority controllers interact with each other through a data transmission unit; The data authority management server is used to process data authority rules and generate new SQL conditions; The permission controller is used to be injected into a business system that needs to perform data entity-based permission management, so that the business system has data permission control capabilities.

2. The data authority control system according to claim 1, characterized in that: The data authority management server includes an application configuration unit, a data entity unit, and a dimension authority processing unit: The application configuration unit is used for parameter configuration of the data rights management server; The data entity unit is used to define and manage the permission rules of data entities, and implement fine-grained permission control over database tables or table sets in the business system; The dimension permission processing unit is used to perform fine-grained data access control between the application layer and the database when the business system initiates a database operation request.

3. The data authority control system according to claim 2, characterized in that: The fine-grained data access control includes: ①SQL interception and parsing The permission controller monitors the database connection channel in real time, captures the original SQL statements through protocol parsing technology, and extracts request context information; ②Acquisition of permission strategy The permission controller passes the request parameters to the data permission management server and obtains the pre-configured permission policy set through the application ID index; ③Data entity processing Perform semantic analysis on SQL to identify the data tables and fields involved, and dynamically generate table association conditions or add filtering conditions based on permission policies; ④SQL reconstruction and execution The processed SQL statements are forwarded to the target database for execution, and the execution results are encapsulated in a standard data format and returned to the business system.

4. The data authority control system according to claim 2, characterized in that: The application configuration unit includes an APP configuration module, a dimension configuration module, and a data entity configuration module: The APP configuration module is used to manage the registration information and authentication parameters of the business system in the data rights management server to ensure the security of rights control and service interaction in a multi-user environment; The dimension configuration module is used to define, manage and apply dimension information The data entity configuration module is used to configure the control relationship between data tables and dimensions on the hit table in actual SQL by establishing mapping rules between data entities, dimension attributes and physical database objects, thereby achieving fine-grained control over the SQL execution process.

5. The data authority control system according to claim 2, characterized in that: The data entity unit includes a table processing module and an SQL condition processing module: The table processing module is used for SQL table structure analysis, table-level permission filtering, multi-table connection condition integration and dynamic SQL reorganization; The SQL condition processing module is used for partial analysis of SQL conditions, authority matching, and dynamic adjustment.

6. The data authority control system according to claim 1, characterized in that: The authority controller includes a business system configuration unit, a custom control unit, and an SQL interception unit. The business system configuration unit is used to perform basic configuration on the business system; The custom control unit is used to precisely control the data permissions of a specific table for query operations involving multiple tables, including data table transfer and access control, as well as flexible settings for query dimensions, so that staff can perform data queries through custom dimensions; The SQL interception unit is used to parse and process the table and condition parts of the select clause in the SQL statement in the business system, combine the user's dimension nodes and the strength control information of the custom control unit, form a new SQL condition and send it to the data authority management server.

7. The data authority control system according to claim 6, characterized in that: The business system configuration unit includes a cache setting module, a communication setting module, and an identity setting module: The cache setting module is used to cache tables and conditions after processing in the data permission server, avoiding the need to spend a lot of time searching in the data permission list each time, saving communication costs and processing algorithm costs; in fact, it adopts a multi-level cache architecture to achieve efficient reuse of permission processing results, thereby reducing system response delays by pre-storing calculation results; The communication setting module is used to set data communication parameters between the data rights management server and the business system; The identity setting module is used to configure user identity information of the business system.

8. The data authority control system according to claim 6, characterized in that: The custom control unit includes an authority control switch, a table pass module, and a custom dimension module: The permission control switch is used to dynamically balance system security and flexibility under the global data permission policy, and temporarily open and close the permission control logic for specific business scenarios or SQL operations; The table pass module is used to process data table front-line transfer or access control; The custom dimension module is used to enable developers to dynamically add new data dimensions to SQL queries based on specific business needs, and flexibly select the logical relationships between these dimensions, thereby achieving more accurate and personalized data screening and querying.

Images