Skip to content

The EBR Compliancy Tool

This tool ensures that the database always remains in an EBR-complaint state.

The Key Rules

Every table must have an Editioning View (EV)

  • Editioning Views act as a stable API layer between application code and underlying tables.
  • This ensures schema changes (adding/removing columns, renaming, etc.) can be managed without breaking dependent objects or application code.

Note

The following tables are excluded from this requirement and do not raise an error:

  • Obsolete tables named OBSOLETE_*_<module>
  • Obsolete tables named *_<numericVersionNumber>
  • Backup Tables named *_BKP or *_BAK

Only Editioning Views can reference real tables

  • No PL/SQL, views, or other objects should directly reference a physical table.
  • This rule enforces strict decoupling and allows us to evolve the table structure without invalidating dependent objects.

Every Materialized View must have a synonym

  • Synonyms provide an indirection layer, allowing us to seamlessly replace or redefine materialized views across editions without impacting application code.

All editionable objects must be created as editionable

  • Objects such as PL/SQL packages, functions, procedures, views, synonyms, and triggers should always be created with the EDITIONABLE keyword.
  • This ensures they can safely exist in multiple editions, supporting rolling upgrades.

Note

TYPE objects, that are referenced by tables, are excluded from this validation.

The EBR Compliancy tool is integrated into the Build Place processes. It will be run as part of the cleanup stage of every installation. This guarantees that our database consistently adheres to EBR compliance.

Identifying and Fixing EBR Compliancy Issues

In the Build Place, if compliancy issues are detected, it will result in a build failures. The build failures will be visible in the _ERROR_post_import.log and _ERROR_cleanup_install.log showing erorrs when calling method Database_SYS.Ebr_Compliance_Check. This will look like this:

To identify which exact objects are affected you can check the following two log files:

  • post_import_<date>_<time>/_ebr_compliance.log which contains information about the following violations:
    • Real Tables that are referenced by objects other than Editioning Views and Cross Edition Triggers
    • Tables and Columns that are marked as obsolete but still referenced by an Editioning View
  • database_cleanup_<date>_<time>/_ebr_compliance.log which contains information about the following violations:
    • Real Tables without Editioning Views
    • Materialized Views without Synonyms
    • Non-Editionable Objects that should be Editionable (mostly TYPE objects)