Method, system and device for setting data authority in database management software

Abstract

The application discloses a method for setting data authority in database management software, which comprises the following steps: creating a data authority attribute, wherein the data authority attribute is coded with a unique ID; configuring the data authority attribute ID to a function information layer or a data dictionary layer, wherein the configuration of the function information layer is prior to that of the data dictionary layer; and assigning data authority to a user who logs in and operates the database management software based on a role and the data authority attribute, so as to control the data that can be seen and modified by the user. For the database-based management software, the data authority of a software operation user can be flexibly set to any table field level in the database, and the management purpose of one-time configuration and everywhere control can be realized.

Description

Technical Field

[0001] This invention relates to the field of database management, and more particularly to a method, system, and device for setting data permissions in database management software. Background Technology

[0002] In database management software, the data users see when accessing specific functions is generally filtered and selected by applying WHERE conditions to SELECT statements in SQL (Structured Query Language). There are typically three types of filtering conditions: the first is fixed filtering conditions directly written into the program during development; the second is user data permission conditions automatically added at runtime; and the third is user-defined filtering conditions set in the user interface. In the second case, where user data permission conditions are automatically added at runtime, adding a viewable data permission condition to the WHERE clause allows control over the data the user can view; adding a modifiable data permission condition and a primary key condition to the WHERE clause, and returning 0 records, indicates that the current user does not have modification permissions for the current data.

[0003] Management software primarily addresses enterprise management issues. However, because enterprises are evolving and possess unique characteristics, even the best management software generally requires secondary development for enterprise application. The larger the enterprise, the greater the potential and scope of secondary development, and the higher the sensitivity to data and the finer the granularity of control. Currently, software on the market, including SAP (System Applications and Products) systems (version ECC EHP7), generally requires software designers to consider data access control—such as specifying which tables' data should be filtered based on which fields and values ​​to control which data users can view and modify—before software development begins. This control code is then written into the specific software functionality (only for those pre-known table fields to be controlled). This leads to a situation where, after the system goes live, if users require data access control for other table fields, the entire software development process must be repeated: submit requirements > code development > testing > deployment. This process is not only inefficient but also introduces stability and other risks due to code modifications, making it extremely costly. Therefore, in management software, it is necessary to uniformly set user data permissions both before and after the system goes live. Summary of the Invention

[0004] One of the objectives of this invention is to provide a method, system, and device for setting data permissions in database management software. This allows the management software to be deployed after development, and even if data permission control is required for table fields that were not adequately considered during the software design and development process, it can still be achieved through a unified setting method. This reduces the need for secondary development and effectively solves the efficiency, risk, and cost problems caused by such requirements.

[0005] Another objective of this invention is to provide a method, system, and device for setting data permissions in database management software, so as to achieve the management objective of "one-time configuration, control everywhere".

[0006] To achieve at least one objective of this invention, the present invention provides a method for setting data permissions in database management software, the method comprising the following steps:

[0007] Create data permission attributes, where the data permission attribute is uniquely encoded with an ID.

[0008] Configure the data permission attribute ID to either the functional information layer or the data dictionary layer, with configuration at the functional information layer taking precedence over configuration at the data dictionary layer; and

[0009] Data permissions are assigned to users who log in and operate the database management software based on roles and data permission attributes;

[0010] In the step of creating data permission attributes, the fields of the data permission attribute table structure are selected from one or more of the following: unique data permission attribute code ID, data permission attribute name, whether to set to apply, data source for value retrieval, SQL for value retrieval, and remarks. The SQL for value retrieval is used to define the values ​​to be used when assigning permissions to users and to facilitate authorization to users by checking boxes. The data source for value retrieval is used to define how the SQL for value retrieval retrieves data from the corresponding database.

[0011] In the step of configuring data permission attributes, the predefined data permission attribute ID is configured on the data dictionary layer or the functional information layer to establish a binding relationship between the two.

[0012] In the step of allocating user data permissions, the data role and the user have a many-to-many relationship. Data authorization is performed based on the user data role ID and data permission attribute ID, which authorizes the user to view and modify which data. When the same user has multiple roles and is authorized on the same data permission attribute, the permissions are taken as the union of the permissions.

[0013] In some embodiments, the step of creating data permission attributes further includes the following steps: determining whether the applied field is set to be default in the data permission attribute table structure. If it is defaulted, it is "N" by default, meaning that no data permission for the data permission attribute has been assigned to the user, and the user cannot see the data. If it is configured as "Y", it means that when the data permission for the data permission attribute is assigned to the user, the data permission conditions assigned to the user are dynamically added to filter the data when the user runs the function, thereby controlling the data permission. If no data permission for the data permission attribute is assigned to the user, no control is performed, and the user can see all relevant data.

[0014] In some embodiments, in the step of configuring data permission attributes, the fields of the data dictionary layer table structure are selected from one or more of the following: table name ID, table name description, field name ID, field description, permission attribute ID, application mode, equivalent table field, and reference SQL. Among these, the combination of the table name ID and field ID fields in the data dictionary layer table structure is unique. The fields of the function information layer table structure are selected from one or more of the following: function ID, function name, dataset ID, table name field name ID, permission attribute ID, and application mode. Among these, the combination of the function ID, dataset ID, and table name field name ID fields in the function information layer table structure is unique.

[0015] In some embodiments, a predefined data permission attribute ID is configured in the permission attribute ID field to establish an association between the two. The application mode field is selected from "SQL application / reference application / apply to both". When configured as "SQL application", the assigned data permission is applied only when the dataset is retrieved to control the visible data. When configured as "reference application", the assigned data permission is applied only when the field value is maintained by reference using a pop-up or drop-down list to control the visible data in the pop-up or drop-down list. When configured as "apply to both", data permission control is performed under both "SQL application" and "reference application" modes.

[0016] In some embodiments, the method for setting data permissions in the database management software further includes the steps of: setting the application mode, equivalence table fields, and reference SQL.

[0017] In some embodiments, the method for setting data permissions in the database management software further includes the step of: storing the data permissions assigned to users in two database tables, wherein the structure of the first user data permission table includes fields such as "user data role ID, data permission attribute ID, viewable data permission, modifiable data permission, and remarks", and the precise data permission values ​​assigned to users by checking boxes are stored in the table as multiple records. The structure of the second user special data permission table is the same as the first table, except that the special data permission values ​​assigned to users are manually entered and stored in the table as single records.

[0018] According to another aspect of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, performs the steps of the data permission setting method in the database management software.

[0019] According to another aspect of the present invention, a device for setting data permissions in database management software is also provided, comprising:

[0020] Memory, used to store software applications.

[0021] A processor is used to execute the software application, wherein each program of the software application correspondingly executes the steps in the data permission setting method of the database management software.

[0022] According to another aspect of the present invention, a data permission setting system in database management software is also provided. The data permission setting system in the database management software includes a permission attribute maintenance unit, a permission application definition unit, and a user permission configuration unit. The permission attribute maintenance unit performs the definition of data permission attributes, the permission application definition unit performs the application definition of data fields, realizing the binding relationship between data permission attributes and a data dictionary layer or functional information layer, and the user permission configuration unit is used to assign data permissions to users. The permission attribute maintenance unit includes an attribute encoding module, a data source module, a value reference definition module, a setting application module, and a remarks module. In the attribute encoding module, the data permission attribute encoding ID is unique; the data source is used to define which database the data permission value to be assigned is retrieved from; the value reference definition module defines the values ​​of the assigned data permission values ​​and the corresponding key display information, which is used to facilitate the selection operation when assigning data permissions; the setting application module is configured such that: when the default is "N No", the user cannot see the data if no data permission for this attribute is assigned to the user; conversely, when configured as "Y Yes", the user can see all relevant data if no data permission is assigned, and can only see the assigned data permission if assigned; the remark module is used to provide prompts to the assignor explaining the purpose of the attribute when assigning data permissions.

[0023] In some embodiments, when there is a new data permission control requirement, the permission attribute maintenance unit maintains a new permission attribute; if the business requires data permission control of warehouse inbound and outbound data, a new record needs to be added.

[0024] In some embodiments, the permission application definition unit is provided with a data dictionary layer permission application definition module. For the data dictionary layer permission application definition module, in the process of applying and defining data permissions based on the database table layer, when the function of the database table is used, the SELECT operation of the database table will be added with the assigned data permission Where condition, thereby achieving unified and consistent data control. The reference application means that it only applies to the data specification selection dialog box.

[0025] In some embodiments, the data dictionary layer permission application definition module includes a table name definition module, a field name definition module, an application mode module, a permission attribute module, and an equivalent table field module. The table names defined by the table name definition module and the field names defined by the field name definition module are unique. The permission attribute module configures the data permission attributes defined in the permission attribute maintenance unit, thereby establishing an association and binding relationship with the data dictionary. The application mode in the application mode module is selected from "SQL application", "reference application", and "apply to all". If the equivalent table field module is configured with this value, it will not need to maintain the subsequent reference SQL, and the reference SQL will be uniformly maintained in the equivalent table field.

[0026] In some embodiments, the permission application definition unit is further provided with a functional information layer permission application definition module. For the functional information layer permission application definition module, the functional layer configuration takes precedence over the data dictionary layer configuration. That is, when a table field name is configured in the functional information layer, the configuration will not be searched for in the data dictionary layer.

[0027] In some embodiments, the user permission configuration unit is provided with a user permission configuration form, which is configured to: assign data permissions under data permission attributes based on data roles or users, and simultaneously assign both viewing and editing data permissions, so as to realize the viewability and modifiability of user permissions. Attached Figure Description

[0028] Figure 1 This is a flowchart illustrating the steps of a method for setting data permissions in database management software according to an embodiment of the present invention.

[0029] Figure 2 This is an example diagram of permission attribute maintenance in a data permission setting system of a database management software according to the above embodiments of the present invention.

[0030] Figure 3 This is an example diagram illustrating the application and definition of data dictionary layer permissions in the database management software according to the above embodiments of the present invention.

[0031] Figure 4 This is an example diagram of the data dictionary layer reference data definition in the data permission setting system of the database management software according to the above embodiments of the present invention.

[0032] Figure 5 This is an example diagram illustrating the definition of the application of permissions at the functional information layer of the data permission setting system in the database management software according to the above embodiments of the present invention.

[0033] Figure 6 This is an example diagram of the user permission configuration form in the data permission setting system of the database management software according to the above embodiments of the present invention. Detailed Implementation

[0034] The following description is intended to disclose the present invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious variations will occur to those skilled in the art. The basic principles of the invention defined in the following description can be applied to other embodiments, modifications, improvements, equivalents, and other technical solutions that do not depart from the spirit and scope of the invention.

[0035] It is understood that the term "a" should be understood as "at least one" or "one or more", that is, in one embodiment, the number of an element can be one, while in another embodiment, the number of the element can be multiple, and the term "a" should not be understood as a limitation on the number.

[0036] This invention relates to computer programs. For example... Figure 1 The diagram shows a flowchart of a data permission setting method in database management software based on the present invention. It illustrates a solution to the problems proposed by the present invention, based on a computer program processing flow, whereby a computer executes a computer program compiled according to the above flow to control or process external or internal objects of the computer. It is understood that the term "computer" in this invention refers not only to desktop computers, laptops, tablets, and other devices, but also to other intelligent electronic devices capable of running programs and processing data.

[0037] The data permission setting method in the database management software described in this invention achieves several advantages. First, it ensures that even after the management software is developed and launched, data permission control for table fields not considered during software design and development can still be implemented through a unified configuration and control method (rather than redevelopment), effectively solving efficiency, risk, and cost issues caused by such requirements. Second, it achieves the management goal of "one-time configuration, control everywhere." If N functions retrieve data from "Table A. Field 3," data permission control can be achieved through a single complete configuration process (i.e., three simple steps: define data permission attributes, associate the attribute with "Table A. Field 3" in the data dictionary, and assign the data permission for the attribute to the user). Then, when a user logs into the system and accesses these N functions, they will only see the data with the assigned permissions.

[0038] Specifically, such as Figure 1 As shown, the method for setting data permissions in the database management software includes the following steps:

[0039] S1100: Create data permission attributes, where the encoded ID is unique;

[0040] S1200: Configure the data permission attribute ID to the functional information layer or the data dictionary layer, wherein the configuration of the functional information layer takes precedence over the data dictionary layer; and

[0041] S1300: Assign data permissions to users who log in and operate the database management software based on role and data permission attributes.

[0042] More specifically, in step S1100, a data permission attribute is created. The data permission attribute table structure includes fields such as a unique data permission attribute code ID, a data permission attribute name, whether to apply, the data source for the value, the SQL for retrieving the value, and a note. It is worth noting that the data permission code is unique, the SQL for retrieving the value is used to define the value used when assigning permissions to users and facilitates authorization to users via a checkbox, and the data source for the value is used to define from which the SQL for retrieving the value retrieves data.

[0043] More specifically, step S1100 further includes the following steps:

[0044] The system checks whether the data permission attribute table structure has an applied field set to default. If it is default, it will be "N" by default, meaning that no data permission attribute has been assigned to the user, and the user will not see the data. If it is configured as "Y", it means that when a user is assigned data permission attribute, the data permission conditions assigned to the user will be dynamically added to filter the data when the user runs the function, thereby controlling the data permission. If no data permission attribute has been assigned to the user, no control will be executed, and the user can see all relevant data.

[0045] More specifically, step S1200 further includes the following steps:

[0046] Configure data permission attributes by assigning the defined data permission attribute IDs to the data dictionary layer or functional information layer, establishing a binding relationship between the two.

[0047] More specifically, the data dictionary layer table structure includes fields such as "table name ID, table name description, field name ID, field description, permission attribute ID, application mode, equivalent table field, and reference SQL". The combination of the table name ID and field ID fields in the data dictionary layer table structure is unique. The function information layer table structure includes fields such as "function ID, function name, dataset ID, table name field name ID, permission attribute ID, and application mode". The combination of the function ID, dataset ID, and table name field name ID fields in the function information layer table structure is unique.

[0048] In some embodiments, configuring data permission attributes at the data dictionary layer is sufficient to ensure that any function retrieving data from a field name in that table is subject to assigned permissions. If certain functions have specific data permission control requirements, data permission attributes can be configured for those functions, with configuration at the function information layer taking precedence over configuration at the data dictionary layer.

[0049] More specifically, the predefined data permission attribute ID is configured in the permission attribute ID field to establish the association between the two; the application mode field has three configuration options: "SQL application / reference application / apply to both". When configured as "SQL application", the assigned data permission is applied only when the dataset is retrieved to control the visible data; when configured as "reference application", the assigned data permission is applied only when the field value is maintained by reference using a pop-up or drop-down list to control the visible data in the pop-up or drop-down list; when configured as "apply to both", the data permission control under both "SQL application" and "reference application" modes is executed.

[0050] Furthermore, step S1200 also includes the following steps:

[0051] Configure the application mode, equivalence table fields, and reference SQL.

[0052] Specifically, reference refers to the maintenance of business data field values. It uses a basic data reference method to ensure data accuracy while facilitating operation. This means the business data field value can only be taken from existing basic data (e.g., the warehouse code field value in inventory inbound / outbound documents must exist in the warehouse code field value of the warehouse file table). Data reference can be implemented through drop-down lists and pop-ups. When the application mode is configured as "Apply Reference" or "Apply to All," data permission filtering conditions will be automatically added to the reference SQL at runtime, ensuring that only data with the required permissions is selected. Introducing the configuration of equivalent table fields simplifies and unifies the settings of reference SQL. References for similar field values ​​can use the same equivalent table field value. For example, the warehouse code and counterpart warehouse fields in the inventory transaction master table both originate from the warehouse code field value in the warehouse file table, and can use the same reference SQL, while also ensuring consistency in the format of the referenced data display.

[0053] Furthermore, step S1300 also includes the following steps:

[0054] User data permissions are assigned, with a many-to-many relationship between data roles and users. Data authorization is based on the user data role ID and data permission attribute ID (i.e., authorizing users to view and modify specific data). In a specific embodiment, the data permissions assigned to users are stored in two database tables. The first user data permission table contains fields such as "user data role ID, data permission attribute ID, viewable data permission, modifiable data permission, and remarks" (where the combination of the user data role ID, data permission attribute ID, and viewable data permission is unique). Precise data permission values ​​assigned to users are typically stored in this table as multiple records (e.g., if a user is only allowed to see inbound / outbound business data with warehouse codes "0016, 0023", there will be two records in this table). The second user special data permission table has the same structure as the first table, except that special data permission values ​​assigned to users are stored as single records (e.g., the user's assigned...). When the warehouse code permission value is "001%, %001, ?001, 0016, 0023", it means that the user can see all warehouses whose warehouse codes begin with the character 001, all warehouses whose warehouse codes end with the character 001, warehouses whose first digit can be any character but whose last three digits must be 001, and warehouses whose codes are equal to 0016 or 0023 (including inbound and outbound business data). Although in most cases, the second table is sufficient to meet the needs of allocating user data permissions, the advantages of using the first table are: 1) the checkbox method is more intuitive and convenient in operation; and 2) when there are many data permission values ​​to be allocated, it is convenient to use the database EXISTS statement to speed up the filtering and data retrieval. The union of permissions is taken when the same user has multiple roles and is authorized on the same data permission attribute.

[0055] Those skilled in the art will understand that embodiments of the present invention can be provided in the form of methods, systems, or computer program products. Therefore, the present invention can take the form of an all-hardware embodiment, an all-software embodiment, or an embodiment combining software and hardware.

[0056] This invention can be embedded in a computer program product, which includes all the features that enable the methods described herein to be implemented. The computer program product is contained in one or more computer-readable storage media having computer-readable program code contained therein. According to another aspect of the invention, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, is capable of performing the steps of the methods of the invention. A computer storage medium is a medium in a computer memory used to store some discontinuous physical quantity. Computer storage media include, but are not limited to, semiconductors, disk drives, magnetic cores, magnetic drums, magnetic tapes, laser disks, etc. Those skilled in the art will understand that computer storage media are not limited to the foregoing examples, which are merely illustrative and not intended to limit the invention.

[0057] According to another aspect of the present invention, a device for setting data permissions in database management software is also provided. The device includes: a software application, a memory for storing the software application, and a processor for executing the software application. Each program of the software application is capable of correspondingly executing the steps in the data permission setting method of the database management software of the present invention.

[0058] Those skilled in the art will understand that the method of the present invention can be implemented by hardware, software, or a combination of both. The present invention can be implemented centrally in at least one computer system, or distributed in a decentralized manner by different parts distributed across several interconnected computer systems. Any computer system or other device capable of implementing the method is applicable. A common combination of hardware and software can be a general-purpose computer system with computer programs installed, controlling the computer system to operate according to the method by installing and executing the programs.

[0059] Corresponding to the embodiments of the method of the present invention, according to another aspect of the present invention, a data permission setting system in database management software is also provided. This data permission setting system in database management software is an application of the data permission setting method in database management software of the present invention in computer program improvement.

[0060] Specifically, in a preferred embodiment of the present invention, the data permission setting system in the database management software includes a permission attribute maintenance unit, a permission application definition unit, and a user permission configuration unit.

[0061] Specifically, the permission attribute maintenance unit performs the definition of data permission attributes;

[0062] like Figure 2As shown, specifically, the permission attribute maintenance unit is configured as follows: when there is a new data permission control requirement, a new permission attribute needs to be maintained in this function. For example, when business requires data permission control for warehouse inbound and outbound data, a new record as shown above can be added. The field meanings are as follows: 1. Attribute Code: Unique is sufficient; 2. Data Source: Defines which database the data permission value to be assigned is retrieved from; 3. Value Reference Definition (SQL): Defines the value to be assigned for the data permission and other key display information, used to facilitate selection during data permission assignment; 4. Setting Application: The default is "N No", meaning that if no data permission for this attribute is assigned to a user, the user will not see the data. Conversely, if configured as "Y Yes", the user can see all related data if no permission is assigned, and can only see the assigned data permission if assigned; 5. Remarks: Used to provide a prompt to the assigning personnel explaining the purpose of this attribute when assigning data permissions.

[0063] The permission application definition unit applies definitions to data fields, thereby establishing a binding relationship between data permission attributes and the data dictionary.

[0064] The permission application definition unit is equipped with a functional information layer permission application definition module and a data dictionary layer permission application definition module.

[0065] like Figure 3 As shown, for the data dictionary layer permission application and definition module, the process of applying and defining data permissions based on the database table layer ensures that any function using that table will have the assigned data permissions (Where conditions) applied to any SELECT operation on that table, thereby achieving unified and consistent data control. Note that the reference application method only applies to the data specification selection dialog box.

[0066] The field meanings are as follows: 1. Table name + field name: unique; 2. Permission attribute: configures the data permission attributes defined in the permission attribute maintenance unit, thereby establishing an association and binding relationship with the data dictionary; 3. Application mode: can be configured as "SQL application", "reference application", or "apply to both" as needed; 4. Equivalent table field: after configuring this value, it is not necessary to maintain the subsequent reference SQL, which is uniformly maintained in the equivalent table field, such as... Figure 4 As shown.

[0067] It is understandable that in other embodiments, there may be a few special functions that require data permission attribute settings different from those of the data dictionary layer. In such cases, different data permission attributes can be configured on these special functional information layers, such as... Figure 5 As shown.

[0068] For the permission application definition module of the functional information layer, the configuration of the functional layer takes precedence over the configuration of the data dictionary layer. That is, if a table field name is configured in the functional information layer, the configuration will not be searched for in the data dictionary layer.

[0069] Furthermore, the user permission configuration unit is used to assign data permissions to users.

[0070] The user permission configuration unit is equipped with a user permission configuration form.

[0071] The user permission configuration form is configured to assign data permissions under data permission attributes based on data roles or users, and can simultaneously assign both view (i.e., view) and edit (i.e. edit) data permissions.

[0072] More specifically, in specific embodiments, such as Figure 6 As shown, the values ​​defined in the data permission attribute maintenance function are generated using SQL to form the data on the right side of this function for easy selection; if you are familiar with the function, you can also directly maintain the additional settings in the lower right corner of this function without selecting the values. The additional settings support wildcards such as "?" and "%".

[0073] According to another aspect of the present invention, a data permission control method is also provided, comprising: when the current user opens a specific function, 1. extracting the data object in the function and traversing to extract its data retrieval statements; 2. parsing the data retrieval statements of the data object and extracting table name and field names from them; 3. extracting the configured data permission attributes based on the table name and field names; 4. extracting the data permissions (divided into viewable and modifiable types) assigned to the current user on the data permission attributes, and generating WHERE conditions that conform to SQL syntax by parsing the table name and field names, and adding them to the original SQL data retrieval statement of the data object. Finally, the method is executed completely to achieve the purpose of controlling which data the current user can view. A method for determining whether the current user has modification permissions for the current row of data is as follows: 1. extracting the data retrieval statement of the data object containing the row of data; 2. parsing to generate the primary key condition for the row of data; 3. extracting the modifiable data permission condition; 4. adding the primary key condition and the modifiable data permission condition to the data retrieval statement of the data object and executing it. If the record count returns 0, it indicates no permission; otherwise, it indicates that the current user has modification permissions for the current row of data.

[0074] More specifically, it includes the following steps:

[0075] S2100: Extract the function ID of the currently opened function (which is unique and can identify the specific function in the system);

[0076] S2200: Extracts all dataset objects of the currently open function and iterates through them, extracting the data retrieval statements (generally database SELECT statements, such as "SELECT ST_StoreHeader.PrimaryID,ST_StoreHeader.WHCODE,...FROM ST_StoreHeader..."; alias formats such as "SELECT A.PrimaryID,A.WHCODE,...FROM ST_StoreHeader A..." are also supported).

[0077] S2300: Parse the data retrieval statement of the dataset object and extract the table name field name (such as the table name field name between SELECT and FROM "ST_StoreHeader.PrimaryID,ST_StoreHeader.WHCODE,..");

[0078] S2400: Extracting Data Permission Attributes: Iterate through the extracted table names and field names above. First, search the function information layer table for data permission attribute IDs (such as WAREHOUSE) and application modes configured at the function layer by function ID, dataset ID, and table name / field name. If found, there is no need to search the data dictionary layer. If not found, search the numeric dictionary layer table for configured data permission attributes and application modes by table name and field name (such as ST_StoreHeader.WHCODE). If the application mode is "SQL application" or "apply to all", continue to execute the following method (i.e., data permissions must be applied before data retrieval).

[0079] S2500: Extract user data permissions: First extract the data role ID of the current user (a user can have multiple roles), then extract the assigned viewable data permission values ​​(e.g., 001%, 0016, 0023) according to the data role ID and data permission attribute ID.

[0080] S2600: Parse data permission values ​​into permission conditions: Combine the data permission values ​​extracted above and assigned to users with the table name and field name to generate a statement that conforms to the database filtering condition syntax (e.g., "(ST_StoreHeader.WHCODELIKE '001%' OR ST_StoreHeader.WHCODE IN('0016','0023'))"; when using aliases, it will be parsed as "(A.WHCODE LIKE '001%' OR A.WHCODE IN('0016','0023'))"; when the assigned permissions are stored in the user data permission table in a multi-record manner, it will be parsed as "EXISTS(SELECT 1 FROM user data permission table UDR WHERE EUDR.User data role ID = current user data role ID AND UDR.Data permission attribute ID = 'WAREHOUSE' AND UDR.Viewable data permission = A.WHCODE)" which can optimize and improve the data retrieval speed of SQL statements).

[0081] S2700: Serializing multiple permission conditions: Data permissions configured on multiple different table field names are merged and serialized using the intersection method, that is, all permission conditions are serialized using the AND method (format: (permission condition 1) AND (permission condition 2)...).

[0082] S2800: Parse permission condition retrieval statement: Add the parsed permission conditions that conform to the SQL filter syntax to the original data retrieval statement of the data object to form a complete data retrieval statement that controls the data that the current user can view (e.g., “SELECT ST_StoreHeader.PrimaryID,ST_StoreHeader.WHCODE,...FROM ST_StoreHeader...WHERE(ST_StoreHeader.WHCODE LIKE '001%' OR ST_StoreHeader.WHCODEIN('0016','0023'))”). Executing this complete statement on the data object retrieves data from the database and displays it to achieve the goal of controlling which data the user can view.

[0083] S2900: Extract user's modifiable data permission conditions: Use a similar method to the one described above, simply change the method from retrieving data from the viewable data permission field of the user data permission table to retrieving data from the modifiable data permission field of the user data permission table.

[0084] S2910: Parse the primary key value condition of the current data: First, extract the original data retrieval statement of the dataset object where the current data is located, extract the primary key field from it (usually the first field in the data retrieval statement, such as ST_StoreHeader.PrimaryID), then extract the primary key field value of the current data, and finally form the primary key condition (such as "ST_StoreHeader.PrimaryID = primary key field value");

[0085] S2911: Method for determining whether data is modifiable: Add the modifiable data permission condition from step S2800 and the current data primary key value condition from step S2900 to the original data retrieval statement of the dataset object containing the current data, forming a complete data retrieval statement to determine whether the current user can modify the data (e.g., "SELECT 1 FROM ST_StoreHeader... WHERE primary key value condition AND current user modifiable data permission condition"). Note: Since only the number of records returned needs to be checked, the fields between SELECT and FROM can be left as 1. After executing this statement, if the number of records returned is 0, it means that the user does not have permission to modify the data; otherwise, it means that the user has permission to modify the current data.

[0086] S2912: Encapsulate functional-level control code: Encapsulate the control methods in S2100 to S2800 above into a single method for easy calling, such as "ApplyDataRight(function is form object)". This allows functions that are not developed using the base form class containing control code to control data permissions simply by adding this one line of code to the code that starts the function.

[0087] S2913: When using the above methods, they can be called individually as needed, or they can be flexibly combined and encapsulated for use.

[0088] S2914: Regarding access control for reference data: After enabling the function, iterate through the table names and field names of the dataset object. Based on the table names and field names, first search for data permission configurations in the function information layer. If not found, search in the data dictionary layer table, extracting the values ​​of fields such as application mode, permission attributes, equivalent table fields, and reference SQL. If the application mode field value is "apply to reference" or "apply to all" and there is a permission attribute configuration, extract the reference SQL field value (if it is empty but there is a configuration value for the equivalent table field, then extract the reference SQL field value from the data dictionary layer table according to the equivalent table field name). Then, extract the data permissions assigned to the current user according to step S2500 above. Finally, according to steps S2600, S2700, and S2800 above, parse and combine the grammatically correct filtering conditions into the reference SQL statement and execute it to obtain the controlled reference data.

[0089] Furthermore, in a specific embodiment of the present invention, a read / write permission system for control data in management software is also provided. Through the read / write permission system for control data in the management software, after the permission administrator assigns function permissions (ignored) and data permissions (described in detail), the user enters their account and password, successfully logs into the system, and opens a specific function. The visible and modifiable data in the function will be controlled by the data permissions assigned to the user in step S1300 of the data permission setting method in the database management software of the present invention.

[0090] Specifically, the management software includes a material document maintenance unit within its data read / write permission control system, which is used to input raw data. The main document table data is displayed as a list.

[0091] The material document maintenance unit performs functions such as adding, deleting, modifying, and querying inbound and outbound business documents for all material warehouses. When a user activates this function, the system automatically adds the data permissions assigned to that user, specifically the inbound and outbound document data for warehouses "0016, 0023, and 0025" allocated in step S1300 of the data permission setting method in the database management software of this invention. If the user attempts to modify row data for warehouses other than 0016, the system will prompt that the user does not have permission to modify this document data. These two controls are a specific application of the SQL application mode.

[0092] The specific application of the reference application mode is as follows:

[0093] When users further configure data filtering conditions in the function interface, they can only select from the data permissions assigned to them (e.g., only the three warehouses assigned to the user in step S1300 can be selected). When adding a new document maintenance warehouse code field value, users can only select from the permissions assigned to them (i.e., the drop-down list above only displays the three warehouses assigned to the user in step S1300 for selection).

[0094] Furthermore, the management software's data read / write permission system also includes a material document query unit to enable the query function of raw data.

[0095] Specifically, documents are generally structured as master-child tables, so this function is designed with two ways to display data: one is a top-bottom method (the top grid displays the master table data of the document, and the bottom grid displays the child table data corresponding to the current document), and the other is a left-right method (that is, displaying the master and child table data together).

[0096] As long as the function is developed based on the base form, it will automatically run the data permission application code (i.e., iterate through the data objects in the function, extract user permissions, apply the data retrieval statement, and then execute the data retrieval) when the function is opened. In a specific embodiment, the warehouse condition in the query conditions can only drop down data with permissions, and the queried data will also be automatically subject to the assigned data permission conditions during the query.

[0097] Furthermore, the data read / write permission system in the management software also includes an inventory entry summary query unit, which is used to summarize and query the raw data.

[0098] It is worth mentioning that the material document maintenance unit, the material document query unit, and the inventory receipt summary query unit all involve retrieving data from the inventory transaction master and sub-tables. Because a single line of encapsulated, generic user data permission application code is placed at the underlying functional level, user data permission conditions are automatically added during data retrieval. This achieves the management goal of "configuration once, control everywhere." In some specific embodiments, the control logic code is exemplified as follows:

[0099] S1. To achieve the goal of "configure once, control everywhere" for data permissions, simply add the following line of code to the form's underlying layer, specifically in the form's creation event:

[0100] TRight.ApplyDataRight(Self); / / Iterate through the functional information layer dataset and apply the data permission conditions assigned to the user.

[0101] The specific encapsulation steps and their implemented functions are described below, involving class library code such as TRight, TProgram, and TDatabase.

[0102] S2. Traverse all datasets in the functional information layer, extract and apply data permission conditions.

[0103] static procedure TRight.ApplyDataRight(AInfo:TInfo);

[0104] var

[0105] liI:Integer;

[0106] begin

[0107] for liI:=0to AInfo.DataSetCount-1do

[0108] begin

[0109] / / Apply data permissions to the dataset in "SQL Appropriation" mode:

[0110] TRight.ApplyDataRight(AInfo.DataSets[liI]);

[0111] / / Apply "reference-based" data permissions to fields in the dataset, including dynamically designing the LookUp interface:

[0112] TProgram.DesignLookUp(AInfo.DataSets[liI]);

[0113] end;

[0114] end;

[0115] S3. Apply user data permission conditions to the dataset, including the dataset fields referencing the data permission definitions.

[0116] static procedure TRight.ApplyDataRight(ADataSet:TDataSet);

[0117] var

[0118] lcDSSQL,lcDataRight:string;

[0119] begin

[0120] if ADataSet is TSQLDataSet then

[0121] begin

[0122] / / Retrieve the original SQL statement for the dataset (this statement is determined during development):

[0123] lcDSSQL:=TSQLDataSet(ADataSet).SQL.Text;

[0124] if lcDSSQL>”then / / Permissions are only required if SQL is defined

[0125] begin

[0126] / / Conditions for retrieving user data permissions (WHERE conditions conforming to SQL syntax):

[0127] lcDataRight:=TRight.GetDataRight(ADataSet,”);

[0128] if lcDataRight>”then

[0129] begin

[0130] / / Add user data permission conditions to the existing SQL statement of the dataset.

[0131] lcDSSQL := TDatabase.AddWhereToSQL(lcDSSQL,lcDataRight); / / Call step 15

[0132] / / Assign the complete SQL statement containing user data permission conditions to the dataset:

[0133] TSQLDataSet(ADataSet).SQL.Text:=lcDSSQL;

[0134] / / Then execute the data retrieval, and you will get the controlled data!

[0135] end;

[0136] end;

[0137] end;

[0138] end;

[0139] S4. Obtain user data permission conditions based on the dataset. When ARightType = 'E', extract the editable (i.e., modifiable) conditions.

[0140] static function TRight.GetDataRight(ADataSet:TDataSet;ARightType:string="):string;

[0141] Within this step, step S5 is called and the permission configuration records are traversed. Step S7 is called to obtain the user data permissions configured on the table fields. The user data permissions configured on all table fields are then combined to generate a complete set of user data permissions for the dataset.

[0142] S5. Retrieve all relevant "SQL application" permission configuration records based on the dataset.

[0143] static function TRight.GetDataRightSet(ADataSet:TDataSet;ATableFields:string):TQuery;

[0144] This step can trace back to the function ID and dataset ID of the input dataset object, and prioritizes extracting permission configuration records with the application mode of "SQL application" or "apply to all" from the function information layer. If no such records are found, permission configuration records are then searched from the data dictionary layer.

[0145] If the parameter ATableFields passed to this step has a value, only the permission records configured on these table fields will be retrieved. If it is empty by default, step S6 will be called to obtain the table fields involved in the dataset (that is, to know which tables and fields the current data should be retrieved from).

[0146] S6. Retrieve all SELECT table_name.field_name, ... statements from an SQL statement. When AType = 'T', only return FROM table_name, ...

[0147] static function TProgram.GetTableFields(ASQL,AType:string):string;

[0148] S7. Retrieve user data permission conditions based on table fields and their corresponding permission attributes. When ARightType = 'E', retrieve edit permissions.

[0149] static function TRight.GetDataRight(ATableField:string;ARightProperty:string=";ARightType:string="):string;

[0150] The sub-steps called within this step are: step S8 (called only when the input parameter ARightProperty is empty), step S9, and step S10.

[0151] S8. Extract the permission attributes configured on the table fields from the data dictionary.

[0152] static function TRight.GetRightProperty(ATableField:string):string;

[0153] S9. Retrieve the data roles for which the current user has been granted permissions on this permission attribute.

[0154] static function TRight.GetDataRole(ARightProperty:string):string;

[0155] S10. Obtain user data permission conditions; the returned value, after parsing, conforms to the WHERE condition in SQL syntax.

[0156] static function TRight.GetUserRight(ATableField,ARightProperty,ADataRole:string;ARightType:string="):string;

[0157] This step first obtains the assigned permissions based on the user data role and data permission attributes, and then parses the table name and field name to generate a WHERE condition that conforms to SQL syntax.

[0158] The sub-steps called within this step are: step S11, step S12, step S13, and step S14.

[0159] Step S14 determines whether the current permission attribute is set to be applied. If it is "Y Yes" and no data permission is assigned, the returned user data permission condition is "7=7". If it is "N No" and no data permission is assigned, the returned condition is "7=8". These specific numbers are used to form the condition to facilitate the identification of permission allocation issues after the system goes online.

[0160] S11. Obtain data permission conditions assigned by the checkbox method (In or Exists format), ARightType = E:Edit to retrieve edit permissions.

[0161] static function TRight.GetInOrExists(ATableField,ARightProperty,ADataRole:string;ARightType:string="):string;

[0162] / / Note: Use IN format for records with selected permissions <100, and EXISTS format for WHERE conditions to improve SQL query performance when the number of records selected is >=100.

[0163] S12. Retrieve data permission conditions assigned in the extra values, supporting wildcard parsing into LIKE syntax format.

[0164] static function TRight.GetExtraValue(ARightProperty:string;ADataRole:string=";ARightType:string="):string;

[0165] S13. Combine the two data permission conditions obtained in steps S10 and S11 into complete user data permission conditions.

[0166] static function TRight.MixDataRight(ADataRight,AExtraVal:string):string;

[0167] S14. Determine if the permission attribute is the "Set and Apply" permission attribute.

[0168] static function TRight.IsSetApply(ARightProperty:string):Boolean;

[0169] S15. Apply a WHERE condition that conforms to SQL syntax to the SQL query statement:

[0170] Static function TDatabase.AddWhereToSQL(ASQL,AWhereCondition:string):string;

[0171] S16. Traverse all fields of the dataset and design field-level LookUp dropdown data references.

[0172] static procedure TProgram.DesignLookUp(ADataSet:TDataSet);

[0173] / / The sub-steps called within this step are: Step S17

[0174] S17. Retrieve the reference SQL from the AField object and apply user data permissions to control the parameter data:

[0175] Note: LookUp is a built-in component of this system platform. Different system platforms may have different methods, but the permission control approach for reference data is the same.

[0176] static procedure TProgram.DesignLookUp(AField:TDataField);

[0177] var

[0178] lcReferSQL,lcReferRight,lcCnFlag,lcDesignStyle:string;

[0179] begin

[0180] if AField.LookupDef.Kind=TLookupKind.lkDataValues ​​then

[0181] / / If this field was designed to maintain its value using a Lookup method during development, simply add user data permissions to the existing SQL statement before retrieving the data.

[0182] Begin

[0183] / / Retrieve SQL statements that were previously not authorized, meaning developers don't need to worry about user data permissions during development!

[0184] lcReferSQL:=AField.LookupDef.SQL.Text;

[0185] / / Retrieve reference data permissions based on the field object

[0186] lcReferRight:=TRight.GetReferRight(AField);

[0187] if lcReferRight>”then

[0188] begin

[0189] / / Apply reference permissions to the original reference statement to generate a reference SQL with the permissions.

[0190] lcReferSQL:=TDatabase.AddWhereToSQL(lcReferSQL,lcReferRight);

[0191] / / Reassign the complete SQL containing user data permissions:

[0192] AField.LookupDef.SQL.Text:=lcReferSQL;

[0193] / / Then execute the data retrieval, and you will get the controlled data!

[0194] end;

[0195] else

[0196] / / If a Lookup design was not performed for this field during development, it can be dynamically designed based on the configuration in the data dictionary:

[0197] begin

[0198] / / Retrieving references from field objects using SQL, data source for reference data retrieval, and LookUp design style:

[0199] lcReferSQL:=TProgram.GetReferSQL(AField,lcCnFlag,lcDesignStyle);

[0200] if(lcReferSQL>”)and(StringUtils.Pos('KEYFIELD',lcReferSQL)>0)then

[0201] / / If the configuration reference uses SQL containing the keyword KEYFIELD, it indicates that the fields should be dynamically designed.

[0202] LookUp

[0203] Begin

[0204] / / Retrieve reference data permissions based on the field object

[0205] lcReferRight:=TRight.GetReferRight(AField);

[0206] / / Apply reference permissions to the configured reference statement to generate reference SQL with the permissions.

[0207] lcReferSQL:=TDatabase.AddWhereToSQL(lcReferSQL,lcReferRight);

[0208] / / Dynamically designing the field object (LookUp)

[0209] TProgram.DesignLookUp(AField,lcReferSQL,lcCnFlag,lcDesignStyle);

[0210] end;

[0211] end;

[0212] end;

[0213] For fields that have been designed as Lookup objects during development, the sub-steps called are: step S18 and step S15.

[0214] For fields of a Lookup designed dynamically at runtime, the following sub-steps are called: step S22, step S18, and step S15.

[0215] S18. Retrieve the reference data permissions (WHERE condition) based on the business field object.

[0216] static function TRight.GetReferRight(AField:TDataField):string;

[0217] The sub-steps called within this step are: step S19, step S21, and step S7.

[0218] S19. Retrieve the relevant "Refer to Apply" permission configuration record based on the field object.

[0219] static function TRight.GetReferRightSet(AField:TDataField):TQuery;

[0220] This step can trace back to the function ID and dataset ID of the input field object, and prioritizes extracting permission configuration records with the application mode of "apply by reference" or "apply to all" from the function information layer. If no such records are found, permission configuration records are then searched from the data dictionary layer.

[0221] The sub-steps called within this step are: Step S20, which determines which table and field to retrieve the data from.

[0222] S20. Obtain the table name and field name of the field based on the field object (knowing which table and field to retrieve the data from).

[0223] static function TProgram.GetTableField(AField:TDataField):string;

[0224] S21. Obtain the reference data permission table field based on the business field object, prioritizing the value of the equivalent table field.

[0225] static function TRight.GetReferTableField(ADataTableField:string):string;

[0226] In most cases, the reference data defined in the reference SQL is usually retrieved from the base data table. In this case, the business table field name cannot be combined with the user data permissions and added to the reference SQL statement. Instead, the field value equivalent to a certain table field (usually the table name or field name of the base data table) must be retrieved from the data dictionary table as the table field for which the reference data permissions are applied.

[0227] S22. Retrieve the configuration reference from the field object using SQL, connect to the data source, and lookup the design style. `static function TProgram.GetReferSQL(AField:TDataField; out ACnFlag:string; outADesignStyle:string):string;`

[0228] The sub-steps called within this step are: step S20, step S23.

[0229] 23. Extract configuration references from the data dictionary based on table field names using SQL, connect to the data source, and use Lookup design styles.

[0230] static function TProgram.GetReferSQL(ATableField:string; out ACnFlag:string; out ADesignStyle:string):string;

[0231] This step first searches the data dictionary table for records where "table_name_field_name = ATableField parameter_value". If the record does not have a "reference SQL" field value but has a "equivalent to a certain table field" field value, it continues searching the data dictionary table for records where "table_name_field_name = equivalent to a certain table field_value". Finally, it returns the configured reference SQL value from that record.

[0232] Those skilled in the art will understand that the invention has been described with reference to flowchart illustrations and / or block diagrams of methods, systems, and computer program products according to the invention. Each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can obviously be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, thereby instructing (the instructions via the processor of the computer or other programmable data processing apparatus) to generate means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or block diagrams.

[0233] Those skilled in the art should understand that the embodiments of the present invention described above and shown in the accompanying drawings are merely examples and do not limit the present invention. The objectives of the present invention have been fully and effectively achieved. The functional and structural principles of the present invention have been demonstrated and explained in the embodiments, and any modifications or variations of the embodiments of the present invention may be made without departing from these principles.

Claims

1. A method for setting data permissions in database management software, characterized in that, The method for setting data permissions in the database management software includes the following steps: Create data permission attributes, where the data permission attribute is uniquely encoded with an ID. Configure the data permission attribute ID to either the functional information layer or the data dictionary layer, with configuration at the functional information layer taking precedence over configuration at the data dictionary layer; and Data permissions are assigned to users who log in and operate the database management software based on roles and data permission attributes; In the step of creating data permission attributes, the fields of the data permission attribute table structure are selected from one or more of the following: unique data permission attribute code ID, data permission attribute name, whether to set to apply, data source for value retrieval, SQL for value retrieval, and remarks. The SQL for value retrieval is used to define the values ​​to be used when assigning permissions to users and to facilitate authorization to users by checking boxes. The data source for value retrieval is used to define how the SQL for value retrieval retrieves data from the corresponding database. The method for setting data permissions in the database management software further includes the following steps: configuring data permission attributes, configuring the predefined data permission attribute ID to the data dictionary layer or functional information layer, and establishing a binding relationship between the two; The data permission setting method in the database management software further includes the following steps: assigning user data permissions, where the data role and user have a many-to-many relationship, authorizing data based on the user data role ID and data permission attribute ID, and authorizing users to view and modify which data permissions, wherein when the same user has multiple roles and is authorized on the same data permission attribute, the permissions are taken as the union of the permissions. The step of creating data permission attributes further includes the following steps: determining whether the applied field is set in the data permission attribute table structure and whether it is default. If it is default, it is "N" by default, that is, no data permission of this data permission attribute is assigned to the user, and the user cannot see the data; if it is configured as "Y", it means that when the data permission of this data permission attribute is assigned to the user, the data permission conditions assigned to the user are dynamically added to filter the data when the user runs the function, thereby controlling the data permission. When no data permission of this data permission attribute is assigned to the user, no control is executed, and the user can see all relevant data. In the step of configuring data permission attributes, the fields of the data dictionary layer table structure are selected from one or more of the following: table name ID, table name description, field name ID, field description, permission attribute ID, application mode, equivalent table field, and reference SQL. Among them, the combination of the table name ID and field ID fields in the data dictionary layer table structure is unique. The fields of the function information layer table structure are selected from one or more of the following: function ID, function name, dataset ID, table name field name ID, permission attribute ID, and application mode. Among them, the combination of the function ID, dataset ID, and table name field name ID fields in the function information layer table structure is unique. The permission attribute ID field configures the predefined data permission attribute ID to establish the association between the two. The application mode field is selected from "SQL application / reference application / apply to both". When configured as "SQL application", the assigned data permission is applied only when the dataset is retrieved to control the visible data. When configured as "reference application", the assigned data permission is applied only when the field value is maintained by reference using a pop-up or drop-down list to control the visible data in the pop-up or drop-down list. When configured as "apply to both", the data permission control under both "SQL application" and "reference application" modes will be executed.

2. The method for setting data permissions in database management software as described in claim 1, wherein the method for setting data permissions in database management software further includes the steps of: setting the application mode, equivalence table fields, and reference SQL.

3. The method for setting data permissions in database management software as described in claim 1 or 2, wherein the method for setting data permissions in database management software further includes the step of: storing the data permissions assigned to users in two database tables, wherein the structure of the first user data permission table includes the fields "user data role ID, data permission attribute ID, viewable data permission, modifiable data permission, and remarks", and the precise data permission values ​​assigned to users by checking boxes are stored in the table as multiple records; the structure of the second user special data permission table is the same as the first table, except that the special data permission values ​​assigned to users are manually entered and stored in the table as single records.

4. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it performs the steps of the data permission setting method in the database management software as described in claim 1 or 2.

5. A device for setting data permissions in database management software, characterized in that, include: Memory, used to store software applications. A processor is configured to execute the software application, wherein each program of the software application correspondingly performs the steps in the data permission setting method in the database management software according to claim 1 or 2.

6. A data permission setting system in database management software, which applies the data permission setting method in database management software as described in claim 1, characterized in that, The data permission setting system in the database management software includes a permission attribute maintenance unit, a permission application definition unit, and a user permission configuration unit. The permission attribute maintenance unit defines data permission attributes, and the permission application definition unit defines data fields, thus establishing a binding relationship between data permission attributes and the data dictionary layer or functional information layer. The user permission configuration unit is used to assign data permissions to users. The permission attribute maintenance unit includes an attribute encoding module, a data source module, a value reference definition module, a setting application module, and a remarks module. In the attribute encoding module, the data permission attribute code ID is unique. The data source module defines which database the data permission value to be assigned is retrieved from. The value reference definition module defines the values ​​of the assigned data permission values ​​and corresponding key display information, facilitating selection during data permission allocation. The setting application module is configured such that, if the default value is "N No", the user cannot see the data if no data permission for that attribute is assigned; conversely, if configured as "Y Yes", the user can see all relevant data if no permission is assigned, and can only see the assigned data permission if one is assigned. The remarks module provides instructions to the assignor explaining the purpose of the attribute when assigning data permissions.

7. The data permission setting system in the database management software as described in claim 6, wherein when there is a new data permission control requirement, the permission attribute maintenance unit maintains a new permission attribute; if the business requires data permission control of warehouse inbound and outbound data, a new record needs to be added.

8. The data permission setting system in the database management software as described in claim 6, wherein the permission application definition unit is provided with a data dictionary layer permission application definition module, wherein, The process of applying data permissions based on the database table layer means that when the function of the database table is used, the SELECT operation on the database table will be subject to the assigned data permission WHERE condition, thereby achieving unified and consistent data control. Among them, the reference application means that it only applies to the data specification selection dialog box.

9. The data permission setting system in the database management software as described in claim 8, wherein the data dictionary layer permission application definition module includes a table name definition module, a field name definition module, an application mode module, a permission attribute module, and an equivalent table field module. The table names defined by the table name definition module and the field names defined by the field name definition module are unique. The permission attribute module configures the data permission attributes defined in the permission attribute maintenance unit, thereby establishing an association and binding relationship with the data dictionary. The application mode in the application mode module is selected from "SQL application," "reference application," and "apply to all." If the equivalent table field module is configured with this value, the subsequent reference SQL does not need to be maintained; the reference SQL is uniformly maintained in the equivalent table field.

10. The data permission setting system in the database management software as described in claim 8 or 9, wherein the permission application definition unit is further provided with a functional information layer permission application definition module, wherein the functional layer configuration takes precedence over the data dictionary layer configuration, that is, when a table field name is configured in the functional information layer, it is not necessary to look for the configuration in the data dictionary layer.

11. The data permission setting system in the database management software as described in claim 10, wherein the user permission configuration unit is provided with a user permission configuration form, and the user permission configuration form is configured to: assign data permissions under data permission attributes based on data roles or users, and be able to simultaneously assign both viewing and editing data permissions, so as to realize that user permissions can be viewed and modified.

Images