{'fraction_non_alphanumeric': 0.01621017328116266, 'fraction_numerical': 0.0, 'mean_word_length': 5.556776556776557, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Constraint based analysis of database update propagation

Current database systems are designed with models which permit definition of objects, relationships, and actions representing "real-world" domains. These modeling constructs provide for the clear specification of the structure of object types, interrelationships between object types, and operations upon objects in the database. A thorough investigation of the constraints and update rules which specify the correct and consistent database states has not yet been carried out. Here, we describe the constraint types associated with the object types and relationships in a database schema and align with each a constraint type, a class of update rules to correctly maintain the database system under the usual primitive update operations (insert, delete, modify object instantiate, remove relationship). 
This work also explores techniques for determining if the schema is correct and consistent once specified. Particular schematic structures which might cause error or prevent clear communication of the design of the system to the implementor and end user are identified. Techniques for detection of these structures are developed and the level of consistency and correctness guaranteed by the removal of these structure types is described. 
This work supplements other research involving triggers, and run-time analysis of update rules by providing a static analysis of the constraint and update characteristics of the database schema during design time. The removal and/or modification of semantics which are redundant, incomplete, or incorrect will simplify the design process and provide a better vehicle for communication to the implementors and end users of the system, and would also facilitate database schema evolution.