Re: Foreign key-type constraints

Question

The methodology my company has defined and uses to attack this problem is
based upon looking for large grain 'business components' within the
business model.
When translating the functionality of the 'business component' to a
physical design we end up with a component object which usually consists of
a major entity(table) and several subsidiary entities and the services
which operate on and maintain those entities i.e. a component object.
We would then remove the referential integrity constraints only between the
components - to be managed by a component reference object - but internally
to the component leave the database referential integrity rules in place.
I beleive this maintains idea of encapsulation as the only way to
communicate with the component is through a defined public service
interface. It also lessens the impact of database changes as they are
usually confined to one componeet and the public service interface to any
other is left intact. It makes use of the database functionality without
dramatically effecting maintenance and performance by writing it all
yourself and/or defining every relationship with the refence manager.
It also leads very much to the definition of large grain reusable
components which can be used in many applications, important to a company
such as mine which develops software for others.
Unfortunately it is not always as simple as it sounds, the methodology helps.
Good database management systems with declarative referential integrity
will usuaually prevent you from defining circular references so you could
test for this by attempting to create the database before you remove the
inter component links. But circular references are much less likely with
the component technique properly applied.
Keith Matthews
Caro System Inc.
www.carosys.com
At 02:07 PM 10/23/97 +0100, John Challis wrote:
We've been pondering the issue of how database integrity should be
represeted within a Forte/OO app. We're thinking, in particular, about
foreign key-type constraints.
First of all, we're not sure whether these constraints should be on the
database, because some would say that this represents business knowledge
which should only be in the app. Also, if constraints are on the
database, the errors you receive if they are violated may not be very
useful; i.e. we're using Oracle, and we'd have to map constraint names
in error messages to some more meaningful message to present to a user.
If foreign key-type constraints aren't on the database, what other
options do we have?
Let's say there's associations between objects X, Y and Z, whereby X and
Y both know about and use Z - we don't want to delete Z while X and Y
exist. I accept that Z should know how to delete itself, from
persistance, but how does it check for the existence of X and Y? If Z
asks objects of types X and Y to check whether they exist in the
database, you can end up with a circular reference. If you do the check
yourself, i.e. by having SQL checking existence of X and Y within the
delete method for Z, then I reckon you've blown encapsulation, and
you've also got a problem in relation to impact if the shape of your
database changes.
We're toying with the idea of having a central integrity manager, which
will tell Z whether it can go ahead with the delete, thus centralising
the integrity constraint knowledge within the app. and minimising impact
of changes to the shape of the database.
I'd be interested to know what others have done to address this issue,
and any thoughts you may have.
Thanks,
John Challis
PanCredit
Leeds, UK
** bassssss **

Answer 1

At 02:07 PM 10/23/97 +0100, you wrote:
...>First of all, we're not sure whether these constraints should be on the
database, because some would say that this represents business knowledge
which should only be in the app. This is a long-winded response, but I tried to relate it to a real-world
example, so bear with me...
Purists may argue with me here, but I must take issue with the notion that
your database cannot have any business knowledge. As soon as you define a
table, you have implicitly given the database business knowledge.
For example, suppose you define a database table Person, with columns Name,
ID, and BirthDate. You are specifically telling the database that there
exists a business "something" called Person which can (or must!) have
values called Name, ID, and Birthdate. You are probably also telling the
database about certain business rules: The value called ID can be used to
uniquely identify a Person; The value Name contains text, and has a maximum
length; Birthdate must conform to the format rules for something of type
Date; etc. Need I go on?
So, to me the argument cannot be that your database should not have any
business knowledge, but rather, what type of business knowledge should be
given to the database?
On the other side of the coin, I also take exception to the argument that
business knowledge belongs only in the Application. In fact, if your
discussion centers around whether business knowledge belongs in the
Application vs. the Database, then maybe both sides are still thinking in
two tiers, and you need to take a step back and think about your business
classes some more.
In our oversimplified example above, we set a limit on the length of the
Name attribute. This is a business rule, and so "belongs" to the business
class. However, our application class needs to have knowledge of that rule
so that it can set a limit on the length of data that it allows to be
entered. Likewise, the persistent storage class must have knowledge of
that rule to effectively store and retrieve the data.
We also have an attribute that is a Date, and a date by definition must
follow certain rules about format and value. The application class and the
storage class will both do their job more effectively if they know that the
attribute is a Date.
Does it break the rules of encapsulation if you allow the application class
or the storage class to have knowledge of certain rules that are defined in
the business class? If it does, then we might as well throw encapsulation
out the door, because it is a totally useless concept in the real world.
Now, let's think about the referential constraints. Suppose you want to
create a business class Employee which inherits from the class Person, and
adds attributes HireDate and Department. When you physically store the
Employee information in your Relational database, you might actually store
two tables, with the ID as a foreign key between them. In this case, the
foreign key relationship would clearly belong to the storage class and the
database. The business class should not know or care whether the Employee
information is physically stored in one table, or two, or twelve.
Now, let's add another business rule, that Employee Department must be a
valid department. To support this rule, you will create a business Class,
Department. For the sake of argument, let us say that the persistent data
for this business class will be stored in a database table, also called
Department.
We have said that there is a relationship between Employee and Department.
Which business class will contain the rule that defines the relationship?
Clearly, it is not Department. Department has no reason to know about
Employee, or any other class that might contain a reference to it. Since
Employee is the one that contains a reference to Department, you could
argue that the rule belongs there. That works fine, until you want to
delete a Department object. Obviously, you would not go to the Employee
class for that. So it seems that the relationship does not belong in
either class.
Someone has suggested that you have an integrity manager or some similar
class for that purpose. The integrity manager would have knowledge of the
rules that define the relationships between your business objects. This
allows you to keep your OO design more "pure" from the standpoint of
encapsulation. Conceptually, this makes good sense, since the relationship
between two classes does not belong to either of the individual classes.
Let's hold that thought for a minute.
Now let's think about your physical database design. I am betting that
there is a high degree of correlation between your database tables and your
business objects. It won't be 100%, because, among other things,
relational databases do not deal well with the concept of inheritance. But
if there is a very wide divergence, then I would need to question the
validity of your design. With that in mind, I am going to propose that you
already have an Integrity Manager, and that is your relational DBMS.
My position is this, that it is ok, even necessary, for the data storage
class to have knowledge of the structure and relationships of the data. It
needs this information to effectively do its job. From my point of view,
saying that you cannot tell the database that there is a relationship
between Employee and Department is just as pointless as saying that you
cannot tell the database that a certain column contains a date, or that
another column contains a unique key which should be used as an index.
Would you argue that an index implies business knowledge, and therefore
does not belong in the database? On the other hand, you could argue that
referential constraints always belong to the physical storage classes,
since they describe under what circumstances data can be stored or deleted.
Now, for performance or other reasons, you might choose not to implement
the Employee-Department relationship in your physical database, and that's
ok, too. Maybe you have decided that since you do not delete departments
very often, that you do not want to incur the database overhead to maintain
the foreign key relationship. Or maybe you have determined that the
Department data will be stored somewhere else other than the database.
Perhaps you would create an Integrity Manager instead, that would only be
invoked when you wanted to delete a Department object. The point is, if
you create an Integrity Manager, be sure you do it for the right reason,
and not because someone has mistakenly decreed that a database cannot have
any business knowledge.
This brings us to the other question, which is: What do you do with the
error if the constraint is violated? Consider this as an option: Create a
User-defined exception named DeleteFailed or something like that. Then it
does not matter if the error comes from the database manager or a separate
Integrity manager. In either case, you fill the exception object with
whatever meaningful data is appropriate, and raise the exception. The
application, which knows what it was trying to do, can listen for the
exception and deal with it appropriately. (btw, this is a good way to deal
with other predictable database exceptions as well, such as DuplicateKey,
or NotFound - your application need not listen for a particular SQL Code or
SQL State, which might tie it to a particular database or storage format.)
I do not see a problem with using the DBMS to define relational
constraints. That is, after all, what a Relational database does. You do
not need an integrity manager for OO-purity, but you can use one if it
makes sense for other reasons. You should be able to change the method of
enforcing the relationships, or even change the entire DBMS without having
any impact on the application classes or the business classes. If you can
meet that test, then as far as I am concerned, you have not violated any
rules of encapsulation.
Any rebuttals?
=========================================
Jeanne Hesler <[email protected]>
MSF&W, Springfield, Illinois
[phone] ext 207
=========================================