Re: Generalised approach to storing address details

> First show me some indication that you understand that the EAV approach > does not use RM as the logical model...

T_Person
Name Gender
john male

In general, the above relation adheres to IP because each tuple's attributes are in the relation's header and the corresponding value is in the cell at the intersection of tuple and column header. Thus, the entire information content of a relational database is represented in one and only one way: namely, as attribute values within tuples within relations.

T_Person
Name Age
john 30 yr

The above table does not violate IP, but violates atomic values and one might resolve it as follows:

T_Person
Name AgeMagnitude AgeUnit

john   30                  yr

The above table, violates IP, in that a relationship between 30 and yr is not encode properly. To actually realize this, let us generalize the table as follows:

Table1
Attrib1 Abttrib2 Atrib3
Val1 Val2 Val3

Now it is easier to see, that we can not assume any relationship between Attrib2 and 3 directly, only that they belong to each tuple. A user encoding relationships between attributeX and attributeY or valueN and valueM violates IP.

T_Hiearachy
Parent Child
john jim

The above table encodes that tuple1's parent is john and tuple1's child is jim, but it does not encode john's child is jim and jim's parent is john, as the user probably intended. The following does so, but introduces NULLs and limits the number of parents and children for each person.

T_Person
name parent child
john jim
jim john

To fix the above problems/limitations,

T_Person
ID name
1 john
2 jim

T_PersonParent
personID ParentID
2 1

T_PersonChild
personID ChildID
1 2

Similarly in EAV, ie

T_Sentence
Subject Verb Object
john like mary

according to IP, we can say sentence1's subject is john, verb is like, and object is mary, but we can't say anything about direct relationships between subject, verb and object as user probably intended.

Many dbs routinely violate IP. In EAV design, the main tables purposely and systematically violate IP to achieve flexiblity to handle complex/varied data or data whose structure is unknown at design time; at the cost of reduced SQL support, db enforced constraints/performance and increased code/complexity.

> > Any data model can theoretically record any proposition. But the
> > ability to do it systematically varies.
>
> "The ability of a system to record any proposition varies"?

Let me clarify. When data (ie complex, varied) starts to fall beyond the beyond the scope of a methodology (ie RM) it starts to use unsystematic methods. Such is the case with RM with respect to hierarchies, graphs, networks and the example below. Alternately, dbd's methodology is more general than RM's. Its method remains consistent whether representing a list, a table, a tree, a graph, a network, etc.

> > Please show how to record the
> > proposition "john likes mary" such that db can answer 1) who likes mary
> > 2) john likes who 3) john does what to mary.
>
> Absolutely irrelevant to what we were talking about..

Below dbd, example represent that john likes mary, john hates bob, and like is opposite of hate. Then a query finds the person with whom john's relationship is opposite that of with mary. One can't implement the following example in a systematic way (ie IP, NULL-less, normalized, non-redundant and remains so when extended) in RM because it's scope, while large, isn't unlimited. It is not imossible, just highly impractical. Try it and post an equivalent RMDB solution.

(new 'john)
(new 'mary)
(new 'bob)

(new 'like)
(new 'hate)
(new 'opposite)

(set like opposite hate)
(set hate opposite like)

(set john like mary)
(set john hate bob)

(; Get person with whom

    john's relationship is opposite of that with mary)
(; Gets bob)
(get john (get (get john * mary) opposite *) *)

(; Get person with whom

    john's relationship is opposite of that with bob)
(; Gets mary)
(get john (get (get john * bob) opposite *) *)
Received on Mon Dec 11 2006 - 04:06:57 CET