Re: database systems and organizational intelligence

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:UpNtc.3$fW5.0_at_newssvr15.news.prodigy.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c97u5m$quc$1_at_news.netins.net...
> > "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> > news:%MItc.4483$G61.3076_at_newssvr32.news.prodigy.com...
> > I see constraints as parameters to a constraint engine that has services
> > that do what would be needed -- pass back what would be needed for a
GUI,
> > validation after receiving data or before storing it. Parameters are
> > typically "declarative" or fill-in-the-blank-data, but the engine itself
> > could be anything, I would think.
>
> Yes, exactly. I think it's a true RDBMS, but it doesn't matter. Dataphor,
> for example, seems to run as either an in-process client-side engine, or
as
> a true server. Unless you're dealing with a Web app (where everything
comes
> from the server), it's critical that the client-side constraint engine be
a
> projection of the server-side - or at least that the two are generated
from
> the same source, or dynamic, or whatever.
>
> I think we're on the same page here, and I think that a
properly-implemented
> RDBMS, AND an environment that takes advantage of it for application
> development, would please you. Forget the "R" and even the "DBMS" if you
> like, and just think of it as a constraint engine.
>
> > > I like Tutorial D, although it's a bit wordy.
> >
> > It makes a good tutorial for relational thinking, but it definitely
> doesn't
> > roll off my fingertips -- it's just too, too, what's the word? I
know --
> > relational ;-).
>
> Yeah, it's a bad name. D4 from Alphora isn't bad... but until I write ERK,
> I'll just never be satisfied, I guess.
>
> > I've used XP in industry and didn't even think of bringing it into a
> > classroom -- good tip!
>
> It works well, even in little 2-hour "brown bags" to a small audience.
>
> > It seems to that Java could be more useful for reusability, thus pushing
> it
> > further up the food chain, than it has been to date.
>
> Yes, you're quite right. Java can be done in very good style, but is too
> often written like a bad translation from COBOL or VB.
>
> > There are some impressive libraries available that help with that.
>
> True, but so many of the libraries are awkward. Reflection, for example,
is
> so awkward that someone had to invent aspect-oriented programming to deal
> with it (yes, that's a gross oversimplification). Compare with
Lisp/Scheme,
> which essentially give you seamless ability to drop in new code, and to
> manage it like your existing code - as data in lists. Not saying this is
> good for everything, but the language itself allows you to define your own
> language, and program in it. Most OO languages get in the way of that
> (Smalltalk doesn't, I think) - an inherent limit on abstraction, which
after
> all was one of the goals of OO.

I thought the aspect programming (of which I have only a tiny bit of knowledge) arose from C# and/or other MS .NET tools handling something better than Java, but that'll have to sit on my someday/maybe pile until it bubbles to the top.

> > Of all of the languages in the mix, the "relational one" (SQL) is one of
> the
> > most problematic, causing us to treat stored data differently than other
> > data, for one thing
>
> I agree with you here, but probably not for reasons you'd like. I wish
> programming languages were "more relational", as opposed to making the
data
> "more graph-like" like XML and OO.

the data IS more graph-like -- I just want to view it as it is ;-) [over-simplification]

> > (and then tied to that bloomin' 1NF for another).
>
> Well, as Date says, 1NF is something of a matter of perspective,

as well as the premise for all of relational theory, being that all normalization requires 1NF to start with

> as long as
> the structures don't intrude on the core relational algebra/calculus. If
> you've got a list type in there, and have defined operators, have at it...
> and in addition, handling such user-defined types nicely in reports and a
UI
> are matters of projecting user-defined types elegantly into the front end,
> something that a good relational-based development environment should do.
I
> think Dataphor does that... have to evaluate to see.
>
> > > Hopefully soon we will have 2 sets of declarations: data (in all its
> > glory,
> > > with full constraints that express the meaning), and components (how
> > > processing components relate - navigation and delegation). Much of the
> > guts
> > > of the components should be generated by the basic data constraints.
> > That's
> > > my hope for the future... and no, I don't mean just one choice, but
> > > certainly fewer choices, constrained by education in basic logic and
> > minimal
> > > thinking (stating what you want and letting the implementation engines
> > > enforce it and generate code).
> >
> > I'm interested in similar goals, but I think the declarative language
for
> > the DBMS being so disjoint from application logic has been significant
> cost
> > to our industry,
>
> Agreed!
>
> > and my take is to move things out of the DBMS to be
> > accessible to the whole system, while others are working to build more
> into
> > the DBMS (especially those who make money selling proprietary DBMS's).
>
> Well, "out of" and "into" aren't precise enough. I'd like them to be
defined
> in one place, and think a constraint engine is a good place. I also think
> the constraint engine should be an RDBMS - no conflict with its
> responsibilities as a constraint engine. Keep in mind that a constraint
> engine has to keep many users happy, and synchronizing factual statements
> various users are making (i.e. writing data, asserting facts, etc.) is a
key
> job. And that fits nicely with what a DBMS does - though today, SQL DBMSs
do
> it badly.

Agreed, except that I'd be fine with spec'ing them in XML and then leaving them in this tree structure for use - no need to do that XML to SQL/RDBMS mapping at all. Additionally, because I want more constraints to be specified by the users and/or end-users AND IGNORED by the database (that's what gets put in the app code today, right?), I see the DBMS constrains as a projection of the application constraints. We can let a user say they want to enter and view address lines as max of 30 characters without the DBMS nosing in on that and fixing that length in the schema, for example. Sure there is a risk, but it is a risk worth taking when there is no fixed reason -- just the whim of the current user -- for sticking to 30 characters. We don't want users knocking down supporting walls without involving IT professionals, but we have got to let them hang pictures and do other makeovers of their applications without requiring an extreme makeover (using doctors).

Relational theory says it is about how to view the data, not how it is stored. In that case, the users know how they want to view it and the constraints should originate from there. I want to design constraints from front to back and not the other way around. Some can stay at the front as "local constraints" (aka application software). Relational theorists seem to have "centralized control" as the key concept. I think I'm a more progressive parent than that. Sure there are risks, but it seemed to have worked with my kids. Users can take responsibility too and recognize the implications of changing the max size of a field by one character, for example, or even switching from storing only numbers as a product ID to permitting alpha-numeric.

> > Maybe if we had a common xml schema for specifying data constraints,
along
> > with common services for applying such, ...
>
> The common schema can be a relational engine. I think you'll find it much
> harder using a tree structure, since rules don't tend to respect
hierarchies
> very well (you can writes rules about hierarchies, but that doesn't mean
the
> rules themselves are easily expressed hierarchically!).

Rules can be built by specifying one function to apply after another -- ands, ors, comparison operators, booleans, etc. A fork-in-the-road function might lead to function A or function B as the next function -- rules are simply trees, even if a simple list tree, right? [I'll admit I didn't think that through completely]

> I'd be interested to
> hear more about the common services for applying them... what do you mean?

One thought on it -- With the distribution of processes across machines and across the network, there are times when you really need to use a synchronous service (or "subroutine", for example), but more often times when an asynch service would be fine (the software analogy to voice mail being highly underused in software applications). I'd like to see a GUI with a message window that doesn't keep interrupting the user like dialog boxes do (hate those things!) but provides information, warning, and error messages.

So, for example, if some aspect of the UI cannot be set up to ensure that the user can only pick a valid option (by providing a list, for example), but must be validated after the user enters data, then after the user addresses that field, but before an entire document is submitted and without tying up the user, the GUI could be a client of a constraint engine service to validate that field. After that service is completed, any messages from the validation could go into the message window, along with messages from other asynch services. The user might then find that they entered an invalid value somewhere before they submit the page.

When they submit a page, the process will know whether it has all data back from the validation services and, if so, will know whether the data has been validated or not.

> > I just haven't seen the fruit from that relational seed
>
> None of us have, although I'd still be interested to hear more from those
> who dealt with old network databases as SQL was coming to the forefront...
> SQL was embraced as solving problems, but did it? Did it solve some and
> introduce new ones?
>
> > and now that it is almost dead, I think I'll skip it ;-)
> > [yes -- just pokin'] Cheers! --dawn
>
> Well, unfortunately (for you) I don't think it's dead yet, and have great
> hopes for its revival.

only if it is greatly fixed, and my take is that the starting point for fixing it is not the current RDBMS implementations. As disturbing as almost the entire IT industry seems to think XML to be from a theory perspective, it aligns much better with the way that users think of their data (primary due to its lack of 1NF and variable length strings that might or might not have tight constraints).

Sorry so long, but thanks for engaging. --dawn Received on Sat May 29 2004 - 00:53:49 CEST