>Hi Evan,
>
>Yes, I can certainly see your point. Obviously we need extreme precision in defining relationships between objects. So what you're telling me is, if the relationship is "works for", then we're talking about 2 different entities.
>
>This implies there is a "list" of relationships that are inter-entity, vs. those that are intra-entity. However, I'm bad at remembering lists - I'd rather derive one or a few rules that work in all cases.
>
>How about this for a start - an object is an "attribute" if it has no meaning except in the context of its "parent/container" object e.g. "blue eyes" is meaningless by itself, but "Al Doman has blue eyes" implies that "blue eyes" is an attribute of the entity "Al Doman", not an entity in itself.
>

Blue eyed Al,

An entity is a person, place, thing, or idea about which we need to record information. RI refers to the validity of the relationships between entities, that is the nature of the PK to FK relationships. I can't think of anywhere where there is an RI issue within a signle entity. Intra-Entity RI, to me, is an oxymoron, if it is internal to a single entity then there is no relationship involved. Even the self relation is actually two enitites, that is two instances of the same entity.

If I design a database and in it I include a table for eyecolor and a table for people, then those are two distinct entities and there is an issue of RI between them. Having Al Doman with an FK pointing to a non-existant eyecolor record is a problem.


If I design a table named employee and have a field in it named MgrID which is an FK to the employee EmpID of the person boss, then there is an RI issue. The MgrID must point to an exitant employee record.

From the persepctive of the database integrity I must insure that these relationships are valid ones, that is they follow the RI rule in the design. However, the business rules will often dictate what the valid state of a relationship is. For example, let's take the common customer to invoice relationship. We know that invoices are supposed to belong to a customer, however, what if the business requires that "Cash" incvoices exist? Should we create a customer named Cash, or should we allow invoices with a blank FK to customer and call them cahs invoices? The design decision will dictate the rules and the design decision is based on the business and not the database requirement that RI be intact. In fact, if we decide that the second option is our design then an invoice with no customer FK is referentially sound.

The original issue here is where should those rules reside in a multi-tiered architecture. My answer is, "It depends on the architectural design." The rules could reside in many places; in the business tier, in the data services tier, in the database itself, or even in an object that serves both the business tier and the data services tier. The place that they "should" be is totally dependent on the architectural design. That is, when the designer built the architecture how did they decide to handle RI? There is no single answer to the question. The answer is, "If the implementation matches the design then that is the right place for the RI." and "If the implementation does not match the design then that is the wrong place for the RI."