Re: In an RDBMS, what does "Data" mean?

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:cagho5$mto$1_at_news.netins.net...
> > And I think I'm seeing more and more value to a path-like / hierarchical
> > expression as a user tool. I see it as best layered atop relational,
since I
> > anticipate more views (if my data is useful, and I'm trying to help the
> > business's departments interoperate) but I think we agree
philosophically
> > with the notion of packaging for the user.
>
> OK, now read what the purpose of the relational model is (somewhere
towards
> the front of Date's latest edition of the textbook).

Don't have it here, but if it suggests making data easy for end-users, that's a myth. Its creators said the same thing about COBOL. Yes there are users who can understand it, but most users have other considerations and want to focus on their tasks. There are always power-users who write reports and queries; they can grok relational, in many cases, and can compose views.

> If "the user" (whether
> a s/w developer or an end-user) can work with data thinking entirely in
this
> walk-our-way-through-the-vocabulary fashion for queries of any sort, then
> what, again was the need for the relational model in this?

In the parlance of Pick, to establish the various vocabularies for various users. To act as its foundation. The minute I have more than one view of the data, I need the model to be neutral (or else you get something like a pipeline of XSLT transforms, which is declarative but easily made intractable). In the case of Pick, though, there's still an implicitly "right" view of the FILE - all of its attributes in gory detail, I assume. That still assumes a hierarchy, meaning other views are relative to that. Basing all the views on a predicate-based structure makes those easier; granted that it gives none of them special status, but I view that as a good thing.

> > Sure, I was being facetious - so there are 2 questions:
> > 1. What is the nature of the "other entities" that will need to use the
> > data?
>
> We will know in time.
>
> > 2. In what form does the data need to be to provide those entities with
> easy
> > access; and even to make those entities easy to develop?
>
> We will know in time.
>
> But we definitely should think about what are the most likely changes on
the
> horizon and what our strategy would be for each of those. I'm not
> completely in the XP camp where we only think about the requirements
> (stories) for this iteration of development and worry about tomorrow,
> tomorrow.

I agree. I think agile arose because big up-front documents suck, and that's still true. What's never been really pushed outside academia are real models, checkable ones, and theorem-proving. Alloy is a nice tool in the model-checking camp; and check out how it subsumes OO-like structures inside relations! In any event, if our designs were concise and checkable, and even used as the basis of code generation, we get correctness and agility in one. But given languages like Java and platforms like the J2EE, while code generation helps, agile is still important. I'm in the Martin Fowler camp, not quite trusting the complete absence of up-front analysis. Like Reagan, I think the agilists talk much tougher than they walk; I think you'd find far more up-front analysis and design than they admit in rhetoric.

> > I see those entities as applications (including GUIs and reports and
batch
> > processes), and contend that relational is the best answer for #2. But
> > hierarchies are useful for #1. The impedance mismatch, though much more
> > tractable at this level than object-relational mappings.
>
> I hope to eventually agree with you on the best approach to #2. That is
not
> the same statement as saying that I hope to eventually agree with your
> current opinion on the matter.

Hey, that's fine... we're just discussing, not brainwashing...

• erk