Re: the database as a language

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:40ce451a$0$568$e4fe514c_at_news.xs4all.nl...
> Dawn M. Wolthuis wrote:
>
> > mAsterdam wrote:
> >>Dawn M. Wolthuis wrote:
> [snipalot]
> > I'm using the term "store" logically,
> > not physically -- it has to do with
> > what predicates (metadata) and propositions
> > (data) have been instantiated.
> > How would you want to state that?
>
> Here is a try:
>
> When talking about predicates and propositions
> I don't really care what gets stored - as long
> as I am assured I can reproduce them in some
> understandable form whenever I need them.
>
> I will store something, put some signs on some
> media, for sure, but I don't think of predicates
> and propositions per se as being the stuff that
> gets stored.
>
> The signs denoting the predicates will help me
> interpret the signs denoting the propositions
> back into the propositions I wanted to
> preserve when I did put them signs on
> those media, i.e. store the data.
>
> (read this aloud in one breath)

I did AND I followed it and it works for me

> [snipalot]
> >>So, the difference is in the software development
> >>process and the tooling of the developers. If
> >>the 'R' people were to prototype - including
> >>using a reporting tool to produce realistic
> >>invoices - there would be no difference in
> >>the output.
> >
> > Perhaps the combination of a reporting tool,
> > the reporting tool's metadata and specification
> > for things like Invoice plus R would be able
> > to give us an M view.
>
> Why the hesitation? Magic? Product loyalty?

I believe more in the former than the latter. No, when considering it, I think of what is encoded "IN" the database as different from the logic that is added after the fact. So, in the case of R, we model the data, losing information that we (likely later and again) design to encode in some third-party tool. Then did R do the trick when combined with reporting-tool? Well, when application N comes along, where is that logic for the system that end-user from M has encoded in some third-party tool? Why not just supplement R with M if adding to it is fair game? Then we know we can accomplish the goals.

> >>>So, M can ignore the fact that it knows
> >>>about an Invoice and can take that invoice
> >>>and normalize the snot out of it and spit
> >>>back the data in that fashion in an effort to
> >>>look R. But R simply lacks the information it
> >>>needs to give us an M picture.
> >>
> >>Because in your example, this needed information
> >>was never expressed in R to start with.
> >
> > DING DING DING DING DING -- that's the problem --
> > there is too much left out when R is being used in
> > order to get around the most severe constraint in
> > the model -- 1NF as SQL understands it.
>
> DONG -- there is too much left out when M puts
> on an effort to look R.
Such as? I've done enough of this to agree with you in part, but the primary reasons in that case were (don't laugh) that field names contained dots and that blankety-blank SQL reserves dots (!!) so they cannot be in attribute names plus M is a two-valued logic while R is (typically) 3VL.

> It doesn't
> provide R with the stuff it needs to look good.
> Appearantly it does not export the markup.

What all is in the markup?

> However, the hiding effort is wasted,
> because R never tried to look good in
> the first place. R plus markup can
> look good, though.
>
> M (appearantly) contains markup it does
> not share when posing as R. So, if you want it
> to look good you 'll have to redo some layout
> work. Makes sense.

not tracking with you on this one

> I don't see a role for 1NF,
> except this: though it is quite possible
> (and done) to have the layout-data normalized
> and construct good looks from them and the
> content-data generically there are just
> too many cheap ways available
> to get the presentation of data
> (input in 1NF) done easier.
>
>
> [snipalot]
> >>I like the 'language' metaphore. It goes beyond
> >>this example. In a way, every database definition
> >>constitutes a language, capable of expressing
> >>statements about truths, relevant to the
> >>business using that database.
> >
> > I can roll with that, but I don't seem to
> > speak that way naturally. You are
> > referring to the predicates, the
> > constraints, the type defs including
> > operators, and the propositions as
> > constituting the language, right?
>
> Not specifically. Even a databases implemented
> as sticking papers on a wall imposes a
> language on the group using it.

agreed.

> [snip]
> >>The gap is there.
> >>I think we already established that SQL is not a complete
> >>tool in this respect. It gets (and updates) data, but
> >>it does a lousy job at showing data nicely.
> >>Most RDBMS come with reporting/form tools to fill in this gap.
> >
> > Perhaps TRDBMS's will cover this gap, but that would not be my guess.
>
> Nor mine - but I have to confess it is on my 'to read' list.
>
> > I still don't see anything that designates one view as more
> > of an entry point for a user than another, for example.
> > It isn't easy for a user to figure
> > out what each row in a view stands for.
> > As soon as we join two tables, we
> > might end up dropping information from one if we used an inner join.
Users
> > know when they go to get Invoices that they then need to narrow it down
to
> > the invoices they want. They don't think in terms of having to toss
more
> > invoices in because this view only shows those where the customer is not
> > deceased and the user didn't know that. The user somehow "feels" more
in
> > control when they are looking through a portal they understand and
grabbing
> > what they need from there (loosely stated objection, of course).
>
> Let's not go into that presentation difference again.
> I think it is clear that it is relevant (IMHO).
> But the way you are mixing, confusing (again, IMHO)
> presentation with other topics such as 1NF does
> not help me at all.

I think I can understand why you think I'm confusing them, but I'm really talking more about some naturally occuring derived data that corresponds to real-world objects (to use Wol's term). There are named "views" of things that matter to the user. This is NOT the presentation, nor even the representation, of whatever data is identified by such. It is the available metadata -- the langauge the user can use.

> [snip]
> > R didn't get the data because it encouraged a lesser
> > implementation to keep pain at a minimum.
>
> Design process, right? Induced (but not
> enforced) by thinking relationally.

yes.

> >>>>It is still interesting to see what kind of expressions
> >>>>fail to translate.
> >>>
> >>>Combination of metadata and data that is designed out of the relational
> >>>model, such as orderings, and attributes with cardinality > 1 that are
> >>>trimmed back to 1 for the relational model.
> >>>
> >>>Did that help or am I digging a deeper hole? --dawn
> >>
> >>Both ;-)
> >
> > Yes, I felt that while falling down into it. smiles. --dawn
>
> Heh. Just kidding. I'm only trying to dig *out*
> stuff, to uncover, as I am hoping/thinking you are
> (but you knew that -- just explaining it for
> the/some others :-)

By the way, my slow speed in responses is due to an ISP that seems to have severely altered the frequency of refreshing their news feed (from minutes to hours it almost seems).

Cheers! --dawn Received on Tue Jun 15 2004 - 03:18:05 CEST