Re: Modeling Data for XML instead of SQL-DBMS

dawn wrote:
> mAsterdam wrote:

>> dawn wrote:
>>> mAsterdam wrote:
[snip]

>>> and when it is only on the nodes that the trees are
>>> found, then I think it should be called by the higher level model, e.g.
>>> di-graph.
>> What makes that higher-level? On which stairway?

"The overall structure" (I assume you mean the web), and the structure of the user data (logical data model) are two different structures. Remarks about one and conclusions about the other? It doesn't work that way.

[snip on/off topic]

>>> I'm actually talking about any DBMS tools that employ 2VL and do not
>>> insist on the form formerly known as 1NF.  Just as David brings up the
>>> DEC Rdb, I bring in tools I know as I'm working on this.
>> You initiated the thread.
>> IMO the topic is very broad already. In the OP it was very fuzzy as
>> well. Drifting further away just isn't going to help anything.

Please, before abstracting, first straighten the question of the OP in your own words.
After your last few posts it still not
clear to me that you understand what I
think is/was wrong with it.

> experience with XML is much more limited than with non-SQL-DBMS tools,
> but questions framed either in the abstract or about data models with
> which I am more familiar are not as productive for me to learn what I
> am trying to learn.

[snip]

>>>>>> How did, working from real examples, the NULLs get in?
>>>>>> Where did they come from? When did they get in?
>>>>> One model related to propositions such as:
>>>>>
>>>>> Amy is married.
>>>>> Hal is divorced.
>>>>> Sylvia is single.
>>>>> Hope is married.
>>>>> We do not have enough information to know whether Lily is married or
>>>>> not.
>>>> The last one is strange mix of non-fact and meta-information.
>>> It is just one of many propositions we need to model with this example.
>> Then answer the earlier question: do we need to know whether Lily is
>> married or not?

>> Why?

When did we realize that 'We do not have enough information to know whether Lily is married or not'?
IOW which business event triggered the creation of this "just one of many propositions" into the closed world?

>> What are we going to do if we still don't know it at a time we need to
>> make a decision based on her marital status - are we going to investigate?

Ah, as far as decision making is concerned, marital status 'unknown' is acceptable? Great! Then let's ditch the expensive recording of marital status altogether, and treat it as unknown always (which is, after all, acceptable).

>>>> Is it stating that we need to know Lily's marital status?
>>> Nope, I don't read that in this set of propositions.
>> You provided the propositions,
>> you know what they are supposed to mean.

Thanks.

The proposed radical simplification of the model will hopefully make the user scratch behind her ears and tell me what the real deal with the marital status is.

>>>> If so, why? What are the requirements?
>>> To model these propositions ;-)
>>>
>>>> Here is another breakdown.
>>>>
>>>> Amy is a person.
>>>> Amy is married.
>>>> Hal is a person.
>>>> Hal is divorced.
>>>> Sylvia is a person.
>>>> Sylvia is single.
>>>> Hope is a person.
>>>> Hope is married.
>>>> Lily is a person.
>>> Sounds like Neo ;-(
>>>
>>>> We still do not have enough information to know whether Lily is
>>>> married or not, but no strange proposition stating that as a non-fact.
>>> Interesting point.  I might propose that depending on the likely target
>>> environment, the requirements from an analysis phase area actually
>>> different.
>> I submit that your set contains implementation
>> consideration, that it is not pure fact.

You do see it's 'the odd one out' character yes? (Dutch: "De vreemde eend in de bijt")
What is odd about it?

> since it was the information that users gave me and
> they didn't know the target environment. But I might accept your
> statement too since a) I don't know what "pure fact" is and b) I do
> think that even in conceptual modeling I would end up with a different
> model if I thought I was headed to a SQL DBMS than if I thought I was
> headed for something else (I might try to talk users out of seemingly
> less-important multivalues in the latter case, for example -- you could
> work with collecting just one phone number and one e-mail address for
> each person, right?)

Please don't fuzzify.

>>> My users think there is nothing strange about the
>>> proposition set I listed.
>>> Your users might be happy with your list
>>> too, but I bet they would suggest mine aligns more with the way they
>>> are thinking about it.
>> You should have had them do the listing.
>> Your solution familiarity colors and clouds
>> your problem observation skills.