Smart Restrict Mode for Database Object Modifications

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional database management systems (DBMS) either prevent modifications to objects with dependent objects, leading to lack of flexibility, or allow modifications that invalidate dependent objects, failing to address scenarios where changes do not result in object invalidation.

Innovation Solution

The introduction of a 'no-invalidation' clause in data definition statements ensures that modifications to database objects only succeed if all dependent objects can be successfully recompiled, preventing invalidation and allowing for controlled changes without affecting dependent objects.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If restrict mode is used to prevent modification of objects with dependent objects, then dependent objects remain valid, but flexibility of database management is reduced

Engineering Contradiction:
Improvevalidity of dependent objectsVSAvoidflexibility of database management
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent changes the parameter of modification restriction from binary (restrict/allow) to a spectrum based on impact assessment. The system evaluates the degree of impact on dependent objects and allows modifications that have no or minimal impact, while blocking only those that cause invalidation. This resolves the contradiction by allowing flexibility for safe modifications while maintaining reliability for critical ones.

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

The patent implements a feedback mechanism where the system automatically evaluates whether a modification would invalidate dependent objects before allowing it to proceed. This feedback loop provides intelligent control, allowing modifications that don't break dependencies while blocking those that do, thus resolving the contradiction between flexibility and reliability.

Inventive Principle:
Principle #23Feedback

2Adaptability or versatility

If smart mode is used to allow all modifications regardless of dependent objects, then flexibility of database management is improved, but dependent objects may become invalid

Engineering Contradiction:
Improveflexibility of database managementVSAvoidvalidity of dependent objects
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent applies preliminary anti-action by evaluating modifications before they are executed to prevent invalidation of dependent objects. The system checks in advance whether a modification would break dependencies and blocks it if so, thus allowing flexibility while preventing the harmful effect of creating invalid dependent objects.

Inventive Principle:
Principle #9Preliminary anti-action

Solution Approach 2:

The system provides feedback about the impact of modifications on dependent objects, allowing the DBMS to make intelligent decisions about whether to permit changes. This feedback mechanism enables the system to allow flexible modifications when safe and prevent them when they would cause invalidation, resolving the contradiction.

Inventive Principle:
Principle #23Feedback

3Reliability

If automatic recompiling is implemented for all object changes, then dependent objects are kept valid, but system complexity and processing time increase

Engineering Contradiction:
Improvevalidity of dependent objectsVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent applies partial action by performing recompiling only when necessary - specifically, only when a modification would invalidate dependent objects. Instead of automatically recompiling all dependent objects for every change, the system selectively applies recompiling based on impact assessment, thus maintaining reliability while reducing unnecessary complexity and processing overhead.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The system changes the parameter of recompiling from mandatory and universal to conditional and selective. By evaluating the impact of modifications and only triggering recompiling when needed, the system maintains dependent object validity while avoiding the complexity and overhead of universal automatic recompiling.

Inventive Principle:
Principle #35Parameter changes

4Reliability

If manual deletion of dependent objects is required before modification, then dependent objects remain valid, but productivity and ease of operation decrease

Engineering Contradiction:
Improvevalidity of dependent objectsVSAvoidspeed of database management operations
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent implements self-service by having the system automatically evaluate and manage the validity of dependent objects during modification operations. Instead of requiring manual intervention to delete or protect dependent objects, the system autonomously assesses impact and either allows the modification or prevents invalidation, thus maintaining reliability while dramatically improving productivity and ease of operation.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system provides automatic feedback about the status of dependent objects and the impact of proposed modifications. This feedback mechanism eliminates the need for manual deletion operations by automatically managing dependency validity, thus maintaining reliability while improving productivity by removing manual steps.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS10120885B2Smart restrict mode for data definition statements
Publication Date: 2018.11.06 SAP SE
  • US10120885B2 patent drawing
  • US10120885B2 patent drawing
  • US10120885B2 patent drawing

AI summary

Example embodiments involve a system, computer-readable storage medium storing at least one program, and computer-implemented method for modifying a database object with one or more dependent database objects. The method may include receiving a data definition statement involving a modification to a database object. The received data definition statement includes a clause imposing a restriction on the modification to the database object. The method further includes determining whether the modification results in invalidation of at least one dependent database object in response to the clause being included in the received data definition statement. Based on determining that the modification results in the invalidation of at least one dependent database object, the modification to the database object is prevented. Based on determining that the modification does not result in the invalidation any dependent database objects, the modification to the database object is performed in accordance with the data definition statement.