Building SOLID Databases: Liskov Substitution Weirdness

if the open/closed principle starts looking a little strange as applied to object-relational design, the liskov substitution principle applies in almost the exactly opposite way in the database as in the applications.  the reason become only clear once exploring this principle, seeing the limits on it, and investigating the realities of database development.  the canonical examples of lsp violations in application programs do not violate the principle at all in the database.  as always the reason is that databases model different things than applications and so their constraints are different.

the formal definition of the liskov substitution principle

let be a property provable about objects of type . then should be provable for objects of type where is a subtype of .

the liskov substitution principle in application programming

the liskov substitution principle is important because it ensures provability of state and behavior for subtypes.  this means you have to look at the full constraints that operate on a class method (excluding constructors i think, which operate under a different set of constraints).

in general for the lsp to be satisfied, preconstraints cannot be weakened, post-constraints cannot be strengthened, and invariants must be maintained not only in inherited methods but also non-inherited ones (this is broad enough to include the history constraint).  the typical problem this addresses is the square-rectangle problem, which is a well-understood problem in object-oriented programming, and one which calls into question certain promises of oop as a whole.

the square-rectangle problem establishes a problem of irreducible complexity in object-oriented programming.  the typical examples are either "a square is-a rectangle" or "a circle is-a elipse."  mathematically both of these statements are true but implementing them in an object-oriented framework adds a great deal of complexity.  the reason is that the mathematical hierarchy has no concept of a change of state which preserves invariances, and so the object hierarchy ends up being complicated by the need to shim in what is notably lacking in the geometric hierarchy.  this leads to either an explosion of abstract classes, an explosion of object metadata (can this rectangle be stretched -- always 'no' for a square)?  can it be scaled?), or a loss of the sort of functionality we typically want from inheritance.

on the database level, these problems mostly don't exist in relational designs but they do exist in object relational designs, only differently (more on that below).

the liskov substitution principle in application programming primarily operates primarily to preserve assumptions regarding state changes in an object when an interface is called.  if a square (defined as a rectangle where x and y measurements are the same) can be stretched, it is no longer a square.  on the other hand, if we can't stretch it, it may not fill the contract of the rectangle.

when a square is-a rectangle subtype

the square-rectangle problem can be turned on its head to some extent with the question of when this is-a relationship is valid.  in fact the is-a relationship is valid for immutable objects.  it is perfectly valid to have a class immutablesquare be a subclass of immutablerectangle.

secondly the subtyping can be valid if sufficient information is attached to the class to specify the invariants.  for example we might have a class with attributes "can_stretch" and "can_scale" where setting can_stretch off (as it would always be in a square) ensures that length to width proportions are always preserved.  the problem here is that the subclass invariances require support in the superclass and this leads to a lot of complexity in implementing the superclass, as well as fundamental limits of what can then be subclassed.

a look at database limitations

in a normal relational database, the lsp is always met.  domain-level constraints only apply to storage and not to calculation outputs, for example.

in database systems where tables instantiate types and substitutability is not anticipated (oracle, db2), then the lsp applies in the same way it does in application programming.  in the cases of table inheritance (informix, postgresql), things start to get a little weird.

for the purpose of stored data, the lsp is generally satisfied because constraints are inherited and strengthened.  a subtype is simply a sub-domain of the parent type possibly with some additional attributes.

the square-rectangle problem in object-relational databases

the square-rectangle problem is only even a potential problem in object-relational databases.  purely relational designs can never run into this issue.  in object-relational designs a few very specific issues can occur depending entirely on how object-relational functionality is implemented at the database level.  in databases like oracle and db2, the lsp applies pretty much as is.  in informix and postgresql, the problems faced are actually somewhat different and lead to new classes of anomilies that need to be considered.  these include most prominently update anomilies when parent tables are updated.  these do not necessarily have easy workarounds.

consider the following table structure:

create table my_rectangle (
    id serial primary key,
    height numeric,
    width numeric
 );

 create table my_square ( 
    check (height = width)
 ) inherits (my_rectangle);

now, we may insert a bunch of squares and rectangles, and we could have checks.  moreover we could have custom triggers to verify referential integrity for rows referencing my_rectangle and my_square.

so suppose we use update on my_rectangle to double the height of every rectangle in the system:
update my_rectangle set height = height * 2;

oops, we can't do that.  while rows in my_rectangle will happily be adjusted, rows in the child table my_square will not, and you will get an error.  this error can be avoided through a few issues, each of which has problems:

1. disallow updates, only allow inserts and deletes.  this makes referential integrity harder to manage when the row must be deleted and re-inserted.
2. use a trigger to rewrite an update to be a delete plus insert into either the current or parent table depending on constraints.  this makes ri harder to manage in that the procedure must disable custom ri triggers before doing this.  this would require that the procedure be aware of all custom ri triggers in order to do this.

conclusions

the liskov substitution principle depends quite a bit on specifics of how an object-relational database system intersects tables and objects for how it applies.  in general in a purely relational design you will never need to worry about it, but in an object-relational design there are some nasty corner cases that can come up, particularly where a query may operate on heterogenous subtypes as a set.  this is, perhaps, the only one of the solid principles which is o-r specific and it hits the db in different ways than the application because the db  operates on different principles.