Device for preventing database table from being mistakenly deleted

Abstract

The invention discloses a device for preventing a database table from being mistakenly deleted. The device comprises a data acquisition module for realizing real-time monitoring and comprehensive data collection; the data processing module is used for performing data analysis, key information extraction, operation identification and abnormal operation marking; the rule engine module learns historical data through a machine learning algorithm, dynamically formulates intelligent rules and realizes real-time database operation analysis and evaluation; the operation decision module is used for making real-time decisions including allowing, stopping and delay operations according to the evaluation result of the rule engine module; the operation intervention module is used for executing a response intervention plan according to an evaluation result of the operation decision module; and the data backup module is used for backing up the data which is possibly subjected to the mistaken deletion risk to a safe storage area and providing a data recovery function. The safety and reliability of database management can be improved, it is ensured that key information in the database is not affected by mistaken deletion operation, and the worry about mistaken deletion risks of a user is relieved.

Description

Technical Field

[0001] The present invention relates to a database table processing device, in particular to a device for preventing a database table from being accidentally deleted. Background Art

[0002] In today's digital age, database management has become an indispensable component of information technology, widely used in the information systems of businesses, institutions, and individuals. Databases store vast amounts of critical data, including but not limited to customer information, financial data, and business logs. However, with the continuous expansion of data volumes and the increasing frequency of database usage, various businesses have become increasingly complex, leading to a constant stream of data structure changes for business launches and routine maintenance tasks. These operations often involve risky operations such as deleting data or deleting and rebuilding tables. Not only are these operations cumbersome, but most complex operations are highly dependent on the expertise of maintenance personnel, making accidental data deletion a common but dangerous problem in database management.

[0003] Accidental data deletion can lead to serious consequences, including information loss, business interruption, and legal liability. Especially in large-scale data processing environments, the risk of accidental deletion cannot be ignored.

[0004] Traditional database management methods primarily rely on technical solutions such as user rights management, database flashback, data backup and recovery, and operation logging to address accidental deletion. However, these methods still face a series of challenges and limitations in practical applications, and cannot comprehensively and effectively address the risks caused by accidental deletion.

[0005] In database management, accidental deletions can occur due to a variety of factors, including human error, malicious attacks, and system failures. Even experienced database administrators find it difficult to completely eliminate the risk of accidental deletions. A simple operational error can permanently delete critical information in an entire table or database, causing severe losses to the organization and business.

[0006] In certain industries, such as finance and healthcare, data security and integrity requirements are particularly stringent. Data loss caused by accidental deletion may not only be an operational error, but may also involve regulatory compliance issues and even lead to legal liability.

[0007] As can be seen from the above, research and innovation on preventing accidental deletion of database data has become extremely important. Therefore, developing an efficient, real-time, and reliable device to prevent accidental deletion of database data has become one of the urgent issues to be solved in the current database management field. Summary of the Invention

[0008] The technical problem to be solved by the present invention is to provide a device for preventing accidental deletion of database tables, which can improve the security and reliability of database management, ensure that key information in the database is not affected by accidental deletion operations, reduce users' concerns about the risk of accidental deletion, and provide enterprises and organizations with a more stable and efficient database management solution.

[0009] The technical solution adopted by the present invention to solve the above-mentioned technical problems is to provide a device for preventing database tables from being accidentally deleted, including: a data acquisition module: realizing real-time monitoring and comprehensive data collection, and providing detailed database operation information for subsequent processing; a data processing module: performing data analysis, key information extraction, operation identification and abnormal operation marking; a rule engine module: learning historical data through machine learning algorithms, dynamically formulating intelligent rules, realizing real-time database operation analysis and evaluation, and converting them into rule knowledge; an operation decision module: making real-time decisions based on the evaluation results of the rule engine module, including allowing, blocking and delaying operations; an operation intervention module: executing response intervention plans based on the evaluation results of the operation decision module, sending alarms in real time, automatically tracking executed intervention plans, ensuring the complete execution of the plans, and returning the execution status to the operation decision module to avoid repeated execution; a data backup module: backing up data that may be at risk of accidental deletion to a secure storage area, and providing data recovery function.

[0010] Furthermore, the data collection module includes: collecting basic information of the database, including database name, version and operating status; collecting information of each data table in the database, including table name, field information, index information, as well as the amount of data in the table, the last update / access time, and the access frequency per minute; collecting SQL statement information in database operations, including specific SQL statements for query, update, insert and delete operations; collecting user information for executing database operations, including user name, role, user connection type, module, IP and port information; collecting permission information of database users and roles, including the permission to add, delete, modify and query different data tables.

[0011] Furthermore, the data processing module includes: parsing the database information, data table information, and SQL statements obtained from the data acquisition module; extracting key information from the parsed data, including operation type, executor identity, SQL type, and operation timestamp; identifying the type of database operation, including delete, update, and insert operations; identifying abnormal operations based on the extracted key information and the identified operation type, and marking them based on the following information: the executor's connection comes from an IP address that does not include production applications; the SQL statement contains the Drop keyword; the SQL statement contains the Truncate keyword.

[0012] Furthermore, the rule engine module builds in all the deletion operation interception rules of the database and calculates the dynamic access risk coefficient of the table in real time in the following manner: S1) Data reading: Read the detailed data of the data table access operations in the real-time and historical databases, including the operation time, operation type, operation database, executing user, and accessed table name; S2) Data cleaning: Clean the discrete data; S3) Data fitting: Perform real-time fitting calculation to generate a quasi-real-time baseline of the access volume per minute Tab_Vis_Per_Min for each data table; S4) Table dynamic access risk coefficient: Generate a risk coefficient Tab_Dy_Vis_Cot based on the access times in the generated baseline:

[0013] Tab_Dy_Vis_Cot = 1 - Tab_Name Tab_Vis_Per_Min

[0014] 0 < Tab_Name <= 1; Tab_Name is the table risk configuration parameter, with a value range of (0 - 1]; when the table access times is 0, the access risk coefficient is 0, and when the access frequency is higher, Tab_Dy_Vis_Cot is closer to 1.

[0015] Furthermore, the discrete data is the access data generated by non-production clients or users.

[0016] Furthermore, the operation decision module reads the risk configuration data in the rule engine module and performs risk assessment on the operations marked as database abnormal operations in real time in the following manner:

[0017] Rule matching: Match the database, user, connection, table information, and SQL operation information related to the abnormal operation marked by the data processing module with the configuration in the configuration rule configuration module, and read the risk parameter values;

[0018] Risk degree calculation: Calculate the risk degree Risk_Score of the database operation according to the result of rule matching and the configuration parameters, and determine the risk level of the operation as: Risk_Score = 100 × (Database × User × Connect) × Tab_Dy_Vis_Cot;

[0019] Risk level division: Divide the operations into high risk, medium risk, and low risk according to the risk degree. The specific division method is as follows: High risk = (80, 100]; Medium risk = (60, 80]; Low risk = (0, 60]; No risk = 0;

[0020] Risk level determination: Combine the result of risk degree calculation with the risk interval to determine the current SQL risk level.

[0021] Furthermore, the operation decision of the operation decision module depends on the risk level of the database operation, and the decision-making process is as follows: allow operation: make a decision to allow for database operations assessed as low risk or no risk to ensure normal business operations; block operation: make a decision to block for database operations assessed as high risk to effectively prevent possible accidental deletion events; delay operation: make a decision to delay for database operations assessed as medium risk, and after approval, the delayed operation calls the data backup module to back up the data before deleting it.

[0022] Furthermore, the operation intervention module includes: determining the conditions for triggering the execution of the plan, configuring the intervention process corresponding to the risk level to form an intervention plan; after the operation decision module makes a blocking or delay decision, sending an alarm notification in real time, the alarm notification includes the type of decision, risk level and specific operation details; executing the corresponding intervention plan according to the decision result, and providing an interface for the administrator to make manual decisions; recording the process and results of the execution of the intervention plan to ensure that each node of the intervention process is fully executed.

[0023] Furthermore, when the operation decision module makes a delayed deletion, the data backup module backs up the data in the source database to the historical database, and then executes the deletion, specifically including: backup configuration: including source database information, historical database information, backup user name and password information, so that the data transmission program can connect the source and destination databases through configuration; table structure migration: the function of backing up and migrating the database table structure to a specified location; exporting the table structure information to a backup file, and transferring it to the destination database for import; data extraction: using ETL or the database's own import and export tools to import the data in the database to import the required backup data from the source database to the destination database; data storage: the function of safely storing the backup data in a specified location.

[0024] Furthermore, the recovery process of the data backup module is as follows: backup data selection: the administrator selects the backup version and data table to be restored; data table structure restoration: restore the structure of the data table to ensure consistency with the backup time; data content restoration: restore the data content in the backup file to the database to restore data integrity.

[0025] Compared with the existing technology, the present invention has the following beneficial effects: the device for preventing accidental deletion of database tables provided by the present invention adds a logical unit to the data access module of the existing mainstream database functional architecture to realize the identification and interception of accidental deletion SQL, ensuring that key information in the database is not affected by accidental deletion operations; at the same time, it adds a double guarantee of active backup of deleted data and can support one-click rapid recovery. This provides a real-time, accurate, and traceable solution to fill the gaps of existing technical solutions and improve the security of database management. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 This is a schematic diagram of the framework of a device for preventing accidental deletion of a database table according to the present invention;

[0027] Figure 2 This is a flow chart of the present invention for preventing accidental deletion of a database table. DETAILED DESCRIPTION

[0028] The present invention will be further described below with reference to the accompanying drawings and examples.

[0029] To address the challenges of existing technologies in preventing accidental deletion of database data, analysis and research have revealed the following problems with existing solutions, including user rights management, database flashback, database backup and recovery, and operation log recording:

[0030] Solution 1: User Rights Management

[0031] (1) Risk of misoperation: Even if user permission management is adopted, high-privilege users may still accidentally perform sensitive deletion operations.

[0032] (2) Complexity of permissions: As organizations grow in size and database structures become more complex, permissions management becomes complex and difficult to maintain. Administrators need to ensure that appropriate permissions are assigned to each user, and changing, revoking, or adding permissions can require significant time and effort.

[0033] (3) Over-empowerment: To avoid missing permissions, administrators may tend to grant users higher permissions, which leads to the problem of over-empowerment. In this way, even a small mistake may lead to significant data loss.

[0034] (4) Difficulty in Auditing: Auditing the changes and use of permissions is key to ensuring system security. However, user permission management systems may lack strong auditing capabilities, making it difficult to track the change history and actual use of permissions.

[0035] (5) Maintenance Difficulty: With organizational changes, staff turnover, and database structure adjustments, permission management requires continuous maintenance. This may involve frequent permission adjustments, and maintaining a complex permission system consumes a lot of manpower and time.

[0036] Overall, practical challenges facing user rights management technology include the risk of misoperation, complexity of permissions, over-empowerment, difficulty in auditing, and maintenance. Therefore, user rights management still cannot completely prevent accidental deletion of database data.

[0037] Solution 2: Database Flashback

[0038] (1) Poor real-time performance: Database flashback is typically a post-deletion recovery method and cannot provide real-time protection against accidental deletions. After an accidental deletion occurs, the administrator can use flashback to restore the database to its previous state. During this time, data may have been lost or damaged, especially in systems where the deletion persists for a long time.

[0039] (2) Performance Overhead: Performing a database flashback operation may introduce certain performance overhead. Especially for large databases, rolling back to an earlier point in time may require a large amount of computing and storage resources, which may affect the performance of normal database services.

[0040] (3) Business inconsistency: Table data in the database usually has business relevance. Flashback recovery of table data using flashback technology may cause business data confusion.

[0041] (4) Increased storage requirements: Database flashbacks typically require maintaining sufficient transaction log information to support restore operations. This may require additional storage space for the database system to store large amounts of historical log information, increasing storage costs.

[0042] While database flashback technology can help recover accidentally deleted data to a certain extent, it's not a perfect solution and doesn't protect against actual deletions. In database management, choosing an appropriate data protection strategy is crucial, taking into account factors such as real-time performance, storage costs, and more.

[0043] Solution 3: Database backup and recovery

[0044] (1) Poor real-time performance: Backup and recovery are usually a post-event recovery method and cannot provide real-time protection against accidental deletions. If an accidental deletion occurs, the administrator can only restore the database to its previous state through backup.

[0045] (2) Storage requirements: Frequent backups may require a large amount of storage space. Especially when the database is large, long-term retention of historical backups may occupy a large amount of storage resources and increase storage costs.

[0046] (3) Recovery methods are complex and time-consuming: Backup and recovery usually need to be performed in another environment, which requires a 1:1 capacity configuration with the original environment to restore all data in the original database to the point in time of deletion. Then, the corresponding table data is restored to the original database through export and import technology. The recovery time is related to the overall database capacity. For larger databases, it may take several days to recover.

[0047] Although database backup and recovery is a common and effective means of data protection, in actual application it is necessary to weigh various factors, select an appropriate backup strategy and retention period, and consider other supplementary measures to improve the security of database management.

[0048] Solution 4: Operation log recording

[0049] (1) Poor real-time performance: Operation logs are usually recorded after the operation has occurred. This means that accidental deletion can only be traced through the operation log after it has occurred, which cannot provide real-time protection against accidental deletion.

[0050] (2) Unable to prevent actual deletion: Operation log records cannot prevent actual deletion operations.

[0051] (3) Difficulty in tracing the operator: Although operation logs can record deletion operations, it is sometimes difficult to accurately trace them back to the specific operator. In some cases, multiple users may share the same permissions, making it difficult to determine which user performed the accidental deletion operation.

[0052] The above analysis shows that database management technologies, such as user rights management, database flashback, database backup and recovery, and operation logging, all suffer from common issues, including poor real-time performance, performance overhead, increased storage requirements, complexity and difficulty in management, inability to prevent actual deletions, difficulty in tracing operators, and challenges in rights management. These technologies typically provide a post-recovery approach to preventing accidental deletions and lack immediate protection mechanisms.

[0053] To address the above issues, this invention proposes an efficient and accurate device for preventing accidental deletion of database tables. This device incorporates key technologies such as real-time auditing and an intelligent rule engine to identify database operations in real time and record key information about all operations, including the type, performer, and execution time. Furthermore, the intelligent rule engine learns from historical operation data to develop operational rules that align with the database's business logic, thereby establishing an intelligent operational risk assessment system.

[0054] The anomaly detection mechanism of this invention dynamically identifies abnormal operations that deviate from normal operating behavior. Once a potential risk of accidental deletion is detected, a real-time alert system is triggered, notifying the administrator to take appropriate measures. Furthermore, this invention implements multi-layered security mechanisms such as two-factor authentication, permission confirmation, and delayed deletion to further reduce the probability of accidental deletion.

[0055] To ensure the ongoing effectiveness of the system, the present invention also implements regular audits and optimization measures, regularly reviewing operational rules to ensure their adaptability and accuracy. Furthermore, system performance and response speed are optimized to minimize the impact on normal database operations. Overall, through a multi-layered security mechanism, the present invention enables real-time database monitoring, risk awareness, and timely recovery, providing an efficient and comprehensive defense for database management and ensuring the integrity and security of the database.

[0056] The present invention adds a logic unit to the data access module of the functional architecture to avoid accidental deletion of data tables; see Figure 1 The present invention includes 6 basic calling modules: 1) Data acquisition module: realizes real-time monitoring and comprehensive data collection, and provides detailed database operation information for subsequent processing; 2) Data processing module: is responsible for parsing and formatting data, performing abnormal operation detection, and ensuring the clarity and accuracy of data; 3) Rule engine module: learns historical data through machine learning algorithms, dynamically formulates intelligent rules, realizes real-time database operation analysis and evaluation, and converts them into rule knowledge; 4) Operation decision module: makes real-time decisions based on the evaluation results of the rule engine, including allowing, blocking, delaying, etc., to deal with database operations with different risk levels; 5) Operation intervention module: executes response intervention plans according to the operation decision results, and sends alarms to administrators in real time. The executed intervention plans will be automatically tracked to ensure the complete execution of the plans. At the same time, the execution status will be returned to the decision module to avoid repeated execution; 6) Data backup module: as an additional preventive measure, data that may be at risk of accidental deletion is backed up to a secure storage area, and one-click recovery is supported.

[0057] The core process of the logic unit of the present invention is as follows: Figure 2 Shown, including:

[0058] 1. Collect database-level, user-level, process-level, table-level, and SQL-level data from the source database.

[0059] 2. The data module cleans the data and extracts key information, while marking abnormal operations according to the rules.

[0060] 3. The operation decision module performs risk assessment based on the risk factor in the rule configuration and the current operation status.

[0061] 4. The operation decision module decides the intervention process according to the risk level. For high-risk cases, the intervention plan is directly executed to intercept, for medium-risk cases, the plan is pushed to the administrator for approval, and for low-risk cases, the plan can be released.

[0062] 5. The intervention tracking module tracks the progress of intervention execution to ensure the complete execution of the plan. That is, for plans with delayed deletion, the data will be backed up to the historical database and then deleted later.

[0063] The present invention uses a data acquisition module to collect indicators of various dimensions such as database, data table, SQL, operating user, user authority, etc., extracts key information after data analysis, identifies abnormal operations, uses an operation decision module to evaluate operation risks, and decides whether to intervene in user abnormal operations based on rule configuration. The operation intervention module corresponds to the intervention plan, and calls the data backup module to remotely back up the data to be deleted and then delays deletion. The present invention solves the problem of accidental data deletion that cannot be solved by existing solutions through the above method. The following is a detailed description of the six basic calling modules of the present invention.

[0064] (1) Data acquisition module

[0065] The data acquisition module can comprehensively and real-timely collect key information from the database, providing an accurate data basis for subsequent risk analysis, rule engine learning and operational decision-making.

[0066] 1. Database information collection: Collect basic database information, including database name, version, operating status, etc. This helps the system understand the overall health of the database and provides basic information for subsequent operations.

[0067] 2. Data table information collection: Collect information about each data table in the database, including table name, field information, index information, as well as the amount of data in the table, the last update / access time, the access frequency per minute, etc.

[0068] 3. SQL Information Collection: This collects SQL statement information from database operations, including specific SQL statements for queries, updates, inserts, and deletes. This helps the system deeply analyze the details of database operations and identify potential risks of accidental deletions.

[0069] 4. Operation User Collection: Collects user information that performs database operations, including user name, role, user connection type, module, IP, port, and other information. This helps the system track the executors of operations and provides a basis for user rights management and risk assessment.

[0070] 5. User Permission Collection: This tool collects the permission information of database users and roles, including the permissions to add, delete, modify, and query different data tables. This helps the system manage user permissions in a fine-grained manner and improves the accuracy of predicting the risk of accidental deletion.

[0071] (2) Data processing module

[0072] The data processing module deeply processes the collected raw data, extracts valuable key information, and provides an accurate and clear data foundation for subsequent intelligent rule engines and operational decision modules:

[0073] 1. Data parsing: Parsing and formatting the raw data obtained from the data acquisition module, converting it into structured data that can be understood and processed within the system. This includes parsing database information, data table information, SQL statements, etc.

[0074] 2. Key Information Extraction: Extract key information from the parsed data, including operation type, executor identity, SQL type, operation timestamp, etc. This helps the system understand database operations more concisely and provides clear input data for subsequent rule engines and decision modules.

[0075] It mainly contains several types of key information:

[0076] (1) Database level: database connection information such as IP, port, database name, schema information, etc.

[0077] (2) User level: user name, roles, and permissions;

[0078] (3) Connection information: the source IP address of the executor and the system domain to which it belongs;

[0079] (4) Data table level: data table size, number of daily accesses, last update time, and related table structure such as fields, indexes, etc.;

[0080] (5) SQL level: SQL type such as Drop, Truncate;

[0081] 3. Operation Identification: Identify the type of database operation, such as delete, update, insert, etc. By identifying the operation type, the system can more accurately determine the nature of the database operation and provide important information for analyzing the risk of accidental deletion.

[0082] 4. Abnormal operation marking: Identify abnormal operations based on the extracted key information and identified operations, and mark them mainly based on the following information:

[0083] The executor's connection originates from an IP address other than the production application's.

[0084] The SQL statement contains the Drop keyword

[0085] The SQL statement contains the Truncate keyword.

[0086] (3) Rule Engine Module

[0087] Rule learning and rule configuration complement each other. Rule learning generates intelligent rules for the system through in-depth analysis of historical data; rule configuration provides administrators with flexibility, enabling them to adjust the system's rule system according to actual conditions. At the same time, through continuous rule learning, the accuracy of deletion judgments is improved to avoid affecting normal business. Both improve the adaptability and customizability of the system.

[0088] 1. Rule configuration:

[0089] Rule configuration allows administrators to flexibly configure system rules based on specific business needs. Since delete operations are usually enumerable, all delete operation interception rules of the database are built into the rule configuration. This includes the following aspects:

[0090] (1) Rule switch control: Provides switch control, allowing administrators to enable or disable specific rules as needed to flexibly respond to different business scenarios.

[0091] (2) Black and white lists: Operation requests initiated from addresses in the configured black and white lists can be directly ignored or blocked without making decisions and interventions based on specific rules.

[0092] (3) Rule priority setting: allows administrators to set the priority order of rules, ensuring that the system evaluates them according to the set priority when processing multiple rules.

[0093] (4) Rule configuration: Rules can be manually added in the rule configuration module, such as SQL statements containing: Drop, Truncate; data table names containing the "CM_BASE" keyword; initiating users other than "USERABC", etc. At the same time, each operation is configured with a corresponding risk factor.

[0094] For example:

[0095] Configuration Type Configuration items Configuration Values Risk Factor Database risk configuration Database Database 1 0 User risk configuration User User 1 1 Connection risk configuration Connect 192.168.1.2 1 Table Risk Allocation Tab_Name Table_ABC (0～1] SQL risk configuration Command Name Drop 1 SQL risk configuration Command Name Truncate 1 SQL risk configuration Command Name Rename 0.6 SQL risk configuration Command Name Alter 0.2

[0096] 2. Real-time calculation of dynamic access risk coefficient of the table:

[0097] Real-time calculation of the risk factor for dynamic table access is an important component of the rule engine module. By statistically analyzing real-time and historical database table operation data, the system can generate a real-time dynamic table access risk factor, enabling a more accurate assessment of the risk impact of various operations on the data table, reducing misjudgments and preventing normal business operations from being blocked. The learning process can include the following steps:

[0098] (1) Data reading: Read the detailed data of access operations of real-time and historical database tables, including operation time, operation type, operation database, executing user, and access table name.

[0099] (2) Data cleaning: Clean the discrete data, such as the access data generated by non-production clients or users.

[0100] (3) Data fitting: Perform real-time fitting calculations to generate a quasi-real-time baseline of the number of accesses per minute Tab_Vis_Per_Min for each data table.

[0101] (4) Table dynamic access risk coefficient: Generate a risk coefficient Tab_Dy_Vis_Cot based on the number of accesses in the generated baseline:

[0102] Tab_Dy_Vis_Cot = 1 - Tab_Name Tab_Vis_Per_Min

[0103] 0 < Tab_Name <= 1; Tab_Name is the table risk configuration parameter, indicating the importance of the table. The more core the table, the smaller the parameter configuration, such as 0.1; for unimportant tables, the parameter configuration is larger, and the maximum can be 1. When the number of table accesses is 0, the access risk coefficient is 0, and when the access frequency is higher, Tab_Dy_Vis_Cot is closer to 1.

[0104] (IV) Operation decision-making module

[0105] The operation decision-making module ensures that the operation decision-making module can quickly and accurately make corresponding decisions based on the real-time risk assessment results, thereby ensuring the compliance and security of database operations, including 3 sub-modules.

[0106] 1. Risk assessment:

[0107] Risk assessment is the primary task of the operation decision-making module. By working in coordination with the rule engine module, read the risk configuration data in the rule engine module, and perform real-time risk assessment on the database operations marked as abnormal, judge the compliance of the operations, and whether there is a possibility of accidental deletion. This function mainly includes the following steps:

[0108] (1) Rule matching: Match the relevant information of the database, user, connection, table information, SQL operations, etc. related to the abnormal operations marked by the data processing module with the configurations in the configuration rule configuration module, and read the risk parameter values.

[0109] (2) Risk degree calculation: Calculate the risk degree Risk_Score of the database operation based on the results of rule matching and configuration parameters, and determine the risk level of the operation.

[0110] Risk_Score = 100 × (Database × User × Connect) × Tab_Dy_Vis_Cot;

[0111] (3) Risk level classification: operations are classified into different risk levels according to the degree of risk, such as high risk, medium risk and low risk. The specific classification method is as follows:

[0112] High risk = (80,100]

[0113] Medium risk = (60,80]

[0114] Low risk = (0,60]

[0115] No risk = 0

[0116] (4) Risk level determination: Combine the risk calculation results with the risk interval to determine the current SQL risk level.

[0117] 2. Operational decision-making:

[0118] After risk assessment, the operational decision module makes real-time decisions based on the risk level, including permission, blocking, and delay. The specific operational decision depends on the risk level of the database operation. The decision-making process includes:

[0119] (1) Allowing operations: Make decisions to allow database operations that are assessed as low-risk or no-risk to ensure normal business operations.

[0120] (2) Blocking operations: Blocking database operations that are assessed as high-risk, effectively preventing possible accidental deletions.

[0121] (3) Delayed operation: For database operations that are assessed as medium risk, a decision to delay will be made. First, the administrator will review and approve the operation. After approval, the delayed operation will call the backup module to back up the data before deleting it.

[0122] 3. Decision-making audit:

[0123] Decision audit is a function that records and audits the operational decision-making process to ensure the transparency and traceability of the system. Specifically, it includes:

[0124] (1) Decision record: records the detailed information of each decision, including decision type, timestamp, executor, etc.

[0125] (2) Audit log: stores the operation log of the decision module, including rule matching status, evaluation results, etc., to provide support for system auditing and optimization.

[0126] (5) Operation intervention module

[0127] The Operation Intervention Module sends timely alerts to administrators after the system makes a decision, provides an interface for manual decision-making, increases system flexibility and user engagement, and records the entire intervention process for auditing and analysis. It consists of four submodules:

[0128] 1. Intervention Plan

[0129] The intervention plan is a feature provided for system administrators to define pre-set operational intervention plans to deal with the risk of accidental deletion. This feature includes the following steps:

[0130] (1) Intervention strategy setting: Define the system's response strategies when facing different risk levels or specific situations, including automatic permission, manual confirmation, delayed operation, permission recovery, session killing, etc.

[0131] (2) Intervention process: Set up a manual decision-making process and combine intervention strategies into a complete intervention plan to prevent accidental deletion.

[0132] (3) Intervention execution configuration: Determine the conditions that trigger the execution of the plan, configure the intervention process corresponding to the risk level to form an intervention plan, such as an intervention plan that executes a response when the risk level reaches a certain level.

[0133] 2. Information push

[0134] After the system makes a blocking or delay decision, it sends an alert notification to the administrator in real time, including decision results, risk assessment and other information, to provide timely feedback. This function includes:

[0135] (1) Alarm notification method: Send alarm notifications to administrators through various methods such as email, SMS, and system interface.

[0136] (2) Information content: The alarm notification contains information such as the type of decision, risk level, and specific operation details.

[0137] 3. Intervention Implementation

[0138] Intervention execution is a function that allows administrators to make manual decisions after the system makes a blocking or delay decision. Specifically, it includes:

[0139] Manual decision interface: provides an interface for administrators to make manual decisions, including options such as confirm permission and continue blocking.

[0140] Plan execution: Execute the corresponding plan based on the decision results.

[0141] 4. Intervention tracking

[0142] Intervention tracking is a function that records and tracks the process of system intervention operations to ensure that all required plans are fully executed. Specifically, it includes:

[0143] (1) Manual decision record: records the detailed information of manual decisions made by administrators, including the type, timestamp, and executor of the manual decision.

[0144] (2) Tracking intervention: Record the process and results of the plan execution to ensure that each node of the intervention process is fully executed.

[0145] (6) Data backup module

[0146] The data backup module backs up the data in the source database to the historical database when the intervention measure is delayed deletion, and then executes the deletion measure. It can ensure that the data can be restored after accidental deletion, and can back up the data to be deleted according to the strategy set by the program, thereby improving the system's fault tolerance for accidental deletion events.

[0147] 1. Back up the configuration

[0148] The backup configuration includes information such as the source database information, historical database information, backup user name and password, so that the data transmission program can connect to the source and destination databases through configuration.

[0149] 2. Table structure migration

[0150] Table structure migration is a function that backs up the database table structure and migrates it to a specified location. The table structure information is exported to a backup file and then transferred to the destination database for import.

[0151] 3. Data Extraction

[0152] Data extraction is to use ETL or the database's own import and export tools to import the required backup data from the source database to the destination database.

[0153] 4. Data Storage

[0154] Data storage is a function that stores backup data securely in a designated location to ensure the reliability and availability of backup data.

[0155] 5. Data Recovery

[0156] Data recovery is the function of restoring backup data to the database in the event of accidental deletion or data corruption. It includes:

[0157] (1) Backup data selection: The administrator selects the backup version and data table to be restored.

[0158] (2) Data table structure restoration: Restore the structure of the data table to ensure consistency with the backup.

[0159] (3) Data content restoration: Restore the data content in the backup file to the database to restore the integrity of the data.

[0160] Compared with user rights management, database flashback, database backup and recovery, and operation log recording solutions, the technical advantages of the present invention mainly include the following points:

[0161] 1. Intelligent risk assessment and decision-making

[0162] By introducing an intelligent risk assessment model and decision-making module, the solution of the present invention can more accurately identify potential accidental deletion risks and has significant advantages in real-time performance. Traditional methods such as user rights management and database backup often lack real-time intelligent risk assessment and decision-making mechanisms.

[0163] 2. Operational intervention mechanism

[0164] The introduction of an Operation Intervention module allows administrators to make manual approval decisions based on actual circumstances, enhancing the system's flexibility and controllability in the event of accidental deletion. Compared to user rights management and database backup, this provides a more direct and proactive means of operation intervention.

[0165] 3. Comprehensive data backup module

[0166] The data backup module includes functions such as backup configuration, table structure migration, data extraction, data storage, and data recovery, ensuring the system has efficient backup and recovery capabilities. Compared with database backup and recovery methods, it provides more lightweight backup and recovery capabilities.

[0167] 4. Combination of rule engine and rule configuration

[0168] This solution combines the intelligent learning of a rules engine with the flexibility of rule configuration, enabling the system to adapt to the business environment through learning while also allowing administrators to configure rules to suit different business scenarios. Compared to traditional user rights management methods, the rules engine provides a more intelligent and flexible management approach.

[0169] 5. Innovation and commercial value of technical solutions

[0170] The proposed technical solution enhances the system's protection capabilities through innovative intelligent risk assessment and operational intervention mechanisms, and has high commercial value. Compared with traditional user rights management and database backup and recovery methods, it provides a more advanced and comprehensive solution.

[0171] In summary, the solution of the present invention has obvious advantages in terms of intelligence, flexibility, comprehensiveness and innovation compared with traditional user authority management, database flashback, database backup and recovery, and operation log recording methods, and can better deal with the risk of accidental database deletion.

[0172] Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art may make some modifications and improvements without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention shall be based on the definition of the claims.

Claims

1. A device for preventing accidental deletion of a database table, characterized in that: include: Data acquisition module: realizes real-time monitoring and comprehensive data collection, and provides detailed database operation information for subsequent processing; Data processing module: performs data analysis, key information extraction, operation identification, and abnormal operation marking; Rule engine module: This module uses machine learning algorithms to learn historical data, dynamically formulate intelligent rules, and implement real-time database operation analysis and evaluation, converting them into rule knowledge. Operation Decision Module: Makes real-time decisions based on the evaluation results of the rule engine module, including allowing, blocking, and delaying operations; Operation Intervention Module: Executes response intervention plans based on the evaluation results of the Operation Decision Module, sends real-time alerts, automatically tracks executed intervention plans to ensure complete execution, and transmits execution status back to the Operation Decision Module to avoid repeated execution. Data backup module: backs up data that may be accidentally deleted to a secure storage area and provides data recovery capabilities.

2. The device for preventing accidental deletion of a database table according to claim 1, wherein: The data acquisition module includes: Collect basic information about the database, including database name, version, and operating status; Collect information about each data table in the database, including table name, field information, index information, as well as the amount of data in the table, the last update / access time, and the access frequency per minute; Collect SQL statement information in database operations, including specific SQL statements for query, update, insert, and delete operations; Collect user information that performs database operations, including user name, role, user connection type, module, IP, and port information; Collect the permission information of database users and roles, including the permissions to add, delete, modify, and query different data tables.

3. The device for preventing accidental deletion of a database table according to claim 1, wherein: The data processing module includes: Parse the database information, data table information, and SQL statements obtained from the data acquisition module; Extract key information from the parsed data, including operation type, executor identity, SQL type, and operation timestamp; Identify types of database operations, including delete, update, and insert operations; Identify abnormal operations based on the extracted key information and identified operation types, and mark them based on the following information: the executor's connection originates from an IP address that does not include production applications; the SQL statement contains the Drop keyword; the SQL statement contains the Truncate keyword.

4. The device for preventing accidental deletion of a database table according to claim 1, wherein: The rule engine module has built-in interception rules for all database deletion operations and calculates the dynamic access risk coefficient of the table in real time as follows: S1) Data reading: Reading detailed data of access operations to data tables in real-time and historical databases, including operation time, operation type, operation database, executing user, and access table name; S2) Data cleaning: Cleaning discrete data; S3) Data fitting: Real-time fitting calculation to generate a quasi-real-time Tab_Vis_Per_Min baseline of visits per minute for each data table; S4) Table Dynamic Access Risk Coefficient: Generates the risk coefficient Tab_Dy_Vis_Cot based on the number of accesses in the generated baseline: Tab_Dy_Vis_Cot=1-Tab_Name Tab_Vis_Per_Min 0 < Tab_Name <= 1; Tab_Name is the table risk configuration parameter, and its value range is (0, 1]; when the number of table accesses is 0, the access risk coefficient is 0, and when the access frequency is higher, Tab_Dy_Vis_Cot is closer to 1.

5. The device for preventing accidental deletion of a database table according to claim 4, wherein: The discrete data is access data generated by non-production clients or users.

6. The device for preventing accidental deletion of a database table according to claim 1, wherein: The operation decision module reads the risk configuration data in the rule engine module and performs risk assessment on the marked database abnormal operations in real time as follows: Rule matching: Match the database, user, connection, table information, and SQL operation information related to the abnormal operation marked by the data processing module with the configuration in the configuration rule configuration module, and read the risk parameter value; Risk degree calculation: Calculate the risk degree Risk_Score of the database operation according to the result of rule matching and configuration parameters, and determine the risk level of the operation as: Risk_Score = 100 × (Database × User × Connect) × Tab_Dy_Vis_Cot; Risk level classification: Classify the operation into high risk, medium risk, and low risk according to the risk degree. The specific classification method is as follows: High risk = (80, 100]; Medium risk = (60, 80]; Low risk = (0, 60]; No risk = 0; Risk level determination: Combine the result of risk degree calculation with the risk interval to determine the current SQL risk level.

7. The device for preventing accidental deletion of a database table according to claim 6, wherein: The operation decision of the operation decision module depends on the risk level of the database operation. The decision-making process is as follows: Allow operation: Make an allow decision on the database operation evaluated as low risk or no risk to ensure normal business operations; Block operation: Make a block decision on the database operation evaluated as high risk to effectively prevent possible accidental deletion events; Delay operation: Make a delay decision on the database operation evaluated as medium risk. After approval, the delayed operation calls the data backup module to back up the data first and then perform the deletion.

8. The device for preventing accidental deletion of a database table according to claim 6, wherein: The operation intervention module includes: Determine the conditions for triggering the execution of the pre-plan, and configure the intervention process corresponding to the risk level to form an intervention pre-plan; After the operation decision module makes a block or delay decision, send an alarm notification in real time. The alarm notification includes the type of decision, risk level, and specific operation details; Execute the corresponding intervention pre-plan according to the decision result and provide an interface for the administrator to make manual decisions; Record the process and result of the execution of the intervention pre-plan to ensure that each node of the intervention process is fully executed.

9. The device for preventing accidental deletion of a database table according to claim 6, wherein: When the operation decision module makes a delayed deletion, the data backup module backs up the data in the source database to the historical database and then performs the deletion. Specifically, it includes: Backup configuration: Include source database information, historical database information, backup user name and password information, so that the data transmission program can connect to the source and destination databases through configuration; Table structure migration: The function of backing up and migrating the database table structure to a specified location; Export the table structure information to a backup file and transfer it to the destination database for import; Data extraction: Use ETL or the import / export tool built in the database to import the required backup data from the source database to the destination database. Data storage: The function of safely storing backup data in a specified location.

10. The device for preventing accidental deletion of a database table according to claim 9, wherein: The recovery process of the data backup module is as follows: Backup data selection: The administrator selects the backup version and data table to be restored; Data table structure restoration: Restore the structure of the data table to ensure consistency with the backup; Data content restoration: Restore the data content in the backup file to the database to restore data integrity.

Images