Re: Generalised approach to storing address details

Neo a écrit :

> > ... it has been established that [EAV] breaks the Information Principle.
>
> >From prior posts, the definition of the Information Principle seems to
> be: The entire information content of a relational database is
> represented in one and only one way: namely, as attribute values within
> tuples within relations.

Information Principle implies that all kind of entities represented in the database are relvars and nothing but relvars....relvar require 2VL.  For several reasons, among which EAV designs can not lead to implement relations, the fact that EAV breaks the cardinality relationship between predicates and relations. 1 relation tuple corresponds necessarily to 1 true proposition and the SAME proposition for all tuples.

Given the following example:

person: person_lname, adress_fname
address_details: adress_value, adress_type, person

What is exactly the predicate that would qualify address_details by validating all tuples as facts ? How do you insure integrity and the cardianlity between the person and adress_details is maintained? How do you handle missing information? How do you avoid redundancy? What if 2 equal values of different user type are stored in adress_details?

In fact, I prefer the follwing more complete definition for IP...

""Information Principle, The

The principle that the only kind of variable allowed in a relational database is the relation variable specifically. (Equivalently, a relational database contains relvars, and nothing but relvars.) Note: It has to be said that this principle isn't very well named. It might more accurately be called The Principle of Uniform Representation, or even The Principle of Uniformity of Representation, since the crucial point about it is that it implies that all information in a relational database is represented in one and only one way-namely, as relations."" Received on Sun Dec 10 2006 - 11:41:00 CET