the database as a language
Date: Tue, 15 Jun 2004 02:38:56 +0200
Message-ID: <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)
[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?
>>>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. It doesn't
provide R with the stuff it needs to look good.
Appearantly it does not export the markup.
However, the hiding effort is wasted,
M (appearantly) contains markup it does
because R never tried to look good in
the first place. R plus markup can
look good, though.
not share when posing as R. So, if you want it
to look good you 'll have to redo some layout
I don't see a role for 1NF,
[snipalot]
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.
>>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.
[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.
[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.
>>>>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 :-) Received on Tue Jun 15 2004 - 02:38:56 CEST