Re: Nulls, integrity, the closed world assumption and events

dawn wrote:
[snip]
> You made a statement with which I disagreed and which I thought was
> what led us to disrupt things in an unfortunate way in the first place.
> I apologize if my response to a statement you thought obvious was
> distracting since I honestly think it is a central issue in how the
> industry took a bad turn.

That's an agenda that wasn't part of the discussion at all, and even though I believe economists would disagree wholeheartedly with you, its just noise. Nevertheless, I take you at your word that you do not intentionally attempt to railroad discussions off in a different angle. The thing is it /does/ seem to happen in every single thread that you get involved with, and once it does, reasonable conversation is over. It would be nice to consciously avoid that, otherwise what's the point of posting on here at all?

>
> > > I, too, think that modeling using relations and applying
> > > set-based functions is good, but do not share your intuition for
> > > splitting up predicates whenever there is a chance of using the form a
> > > null that works with 2VL.
> >
> > You should do though! Why? Because even though an empty set is a value
> > the propositions we state, and predicates we use to describe
> > commonalities, do not contain sets, and would only extremely rarely
> > ever mention sets. I think entrenched techie processes have clouded
> > your intuition - you are thinking in terms of record systems, and what
> > will fit in the 'holes' they engender, instead of considering that when
> > we state facts, by definition, they have no holes! Never!
>
> I'm hesitant to disagree because I suspect this is another truism. I
> will make a couple of comments, however.

So you are swaying to the fact that propositions with holes in them are unintuitive after all? Its okay to do that y'know, it has no effect on non-theoretical arguments.

>
> 1) modeling with 2VL and nulls works very well. We have thrown it out
> before, as an industry, thinking that it did not align well with some
> theory. We should be careful to simply toss out what works well.

It makes no economic sense that producers would throw out something out that works well without something better replacing it. More importantly /I have never said anyone ever should/. This is again rather frustrating, as the inference is that the comment contends something I have said, which it absolutely does not. I am sure you are not intentionally trying to put words in my mouth, just so there is something to disagree with, but again this all has no relevance to the theory of what we were discussing.

>
> 2) When we collect and show data to a human, we are often collecting it
> with "blanks" and then showing it back to the user with blanks. For
> example, they might have a screen and related reports where the
> proposition Person 12345 is a male named John Doe whose hair color is
> _________. The user sees the blank and does not fill it in, either
> because John Doe is bald or because they do not know his hair color.
> Someone else then sees a report that might provide this very
> proposition back.

This is so wrong my head is starting to hurt. I think it may be the fundamental point that you are grappling with. A record is not a proposition. A proposition is not a record. With all the discussions you've had on cdt it worries the bejeezus out of me could one still be confusing the two. Propositions do not have holes. Records can do.

Entities and Records = conceputal layer, Database = logical layer, and never the twain should meet in logic. Entities, Objects & Records are constructed from propositions, query and build - that's at the heart of how we communicate (and why people miscommunicate because they have different rules and contexts for building those entities in their heads).

Have you looked at that book "Data and Reality" by William Kent that I once recommended to you? It really helped me recognize that 'record' mistake, and I think it would be an invaluable read in this case.

> It is ambiguous, but if it were important that it
> not be, then we could have collected additional data and insisted that
> the data entry person tell us why they are leaving it blank. Human
> beings are working with these propositions that include blanks
> repeatedly, performing logical functions based on them. It seems that
> we could model human language and behavior with our stored propositions
> and do likewise. In other words, when we model the propositions the
> way the user does, we are simulating human behavior, the behavior that
> humans would use if the data were stored on paper forms in file
> cabinets. It is the way a person would intuitively work with the data.
> If we cannot simulate this with a computer, then why not? Again, it
> seems to work very well and from what I have seen, users using systems
> with this approach to NULL have fewer problems with querying and
> working with it. The system then "think like" they do.
>
> > And to think in terms of holes like this really isn't intuitive - for
> > example, say you're writing some XML document. You are hardly going to
> > create a tag with nothing in it, when you could have just left the tag
> > out altogether are you?
>
> If it is an XML document to back a report to the user, one might do so.
> If we are repeating the tags for each column with each row of data,
> then (ugly as that is), so be it. For a null value, I would think you
> would have <hairColor /> (or <hairColor></hairColor>) for that row in
> your XML.
>
> > The logic you are following is asking me to put
> > in that tag with an empty set inside it.
>
> Yes, or the shorthand version of that in XML.
>
> > Framed this way it seems like
> > madness (if still preferable to putting an sql-null in there).
>
> Ah, but it isn't, and likely results in less madness than the SQL
> approach.

Again frustrating!

• You've neglected the point that I was showing you it was /unintuitive/, not possible as some bodge in a specific case.
• This was nothing to do with SQL, it was about the uninuitiveness of holes in propositions, why bring something orthogonal like SQL back in!
• I could not believe for a moment that someone (especially one who refers to trying to stick good practices) would ever commend an employee for generating like <person><cars>{}<cars></person> instead of just having no tag at all.

>
> > > I was advocating migrating from the "legacy"
> > > Pick approach to and SQL-DBMS approach when I was hit over the head
> > > repeatedly with the fact that it was more intuitive for developers and
> > > end-users, resulting in fewer data and process defects when using null
> > > as empty set with 2VL than null as unknown with 3VL. I suspect there
> > > would be few, if any, folks who have worked with each who prefer 3VL
> > > and related relational decomposition.
> >
> > I do not see the coupling you make with 3VL and 6NF.
>
> I don't recall where 6NF was in this mix, but my understanding is that
> many (not all) put the elimination of nulls into 1NF and all subsequent
> NF's are built on top of that. I did not intend to couple 3VL with 6NF
> per se and I don't even recall that 6NF was in this discussion.

The connection was that 6NF is the last word in relational decomposition down to irreducible tuples. Let me restate then - I don't see what 3VL has to do with relational decomposition at all, so I thought the paragraph this references was yet another red-herring.

The rest I will leave to a later post. Received on Thu Jan 18 2007 - 22:43:14 CET