Logical independence

An important feature of a DBMS is to support logical independence.

This allows for immunity of user applications to changes made in the database schema.

Often data tends to be produced by one application and consumed by many more. Read only views handle logical independence extremely well for the applications that only read data. Under the RM, defining a read-only view could hardly be easier - just use the relational algebra to define derived relvars.

A read only view can involve a non-injective function of the base relvars - i.e. it can easily remove information, and impose constraints.

A good DBMS will optimise the I/O and caching of the read only views, and allow them to be updated efficiently with incremental computing.

This is much simpler than for example using ORM to map relations in the database to objects and writing procedural code to query the objects, cache derived variables and send messages or implement a bunch of methods of some interface.

In other words logical independence involving stable views is far superior to OO solutions involving stable message types, or stable interfaces.

View update problem

Logical independence works well for readers but not so well for writers. This is called the view update problem.

Consider the example of an insert into a restriction.