screendata (was something NULL)

paul c wrote:
> mAsterdam wrote:

>> paul c wrote:
>>> dawn wrote:
>>>> ...
>>>> I'm presuming no such thing.  I'm talking about the model of the data
>>>> needed for the screen.  To answer David's question too, if you were to
>>>> prepare a diagram of your choice, perhaps UML these days, of the
>>>> logical data model that a software application needs for interfacing
>>>> with the database and the logical model it needs for the UI, choosing
>>>> the same entities and attributes to model, your UML diagrams would be
>>>> different.  Given there is an industry arising from this along with the
>>>> OO-RM impedence mismatch, I think this is rather well established.
>>>>
>>>> We take data in from a screen as strings, change them to objects based
>>>> on specifications in code or parameter data, and then to relations
>>>> based on specifications in code or parameter data, with each process
>>>> validating everything along the way.  The RDBMS takes those relations,
>>>> validates with constraint logic likely written in a different language
>>>> than the other validations, and turns the data into strings to be
>>>> stored.
>>>>
>>>> That doesn't seem efficient in either machine or people time for both
>>>> development and maintenance activities.  Or am I missing something?
>>>
>>> Dawn, I think you are on the right track, but I think you must throw 
>>> out some of the conventional lingo/arguments before it goes 
>>> anywhere.  F... (you know what i mean) the 'modelling', etc.  The 
>>> data has already been modelled.  Just my 2 cents.
>>
>> The screen-data? How?

We should have a screen model, part of which is a data model, to be able to design it without immediately having to build it. The screen will be used to show/input data of one or more databases, so this screen data model reflects parts of the datamodel of the those databases.

> They have only a
> programming model, also very little notion of persistence. The reason I
> make this distinction is that I think the programming model should be
> subservient to the data model which may have many programming
> manifestations. The main advantage of this viewpoint for me at least is
> that the RM data model is fairly spare and reasonably easy to assess
> vis-a-vis a particular implementation as to whether it has been
> followed. I should say that I don't claim to be a relational expert,
> more of an amateur student and also that many of the recognized experts
> are known to disagree on various fundamental points.
>
> If we're talking about the RM, it does have a data model and the key
> concept is obviously that of the view, aka relational expression.

The 'it' stops being a screen, though.

> When
> it comes to updating by an interactive user, the RM doesn't seem to say
> much if anything. So I think a notion of 'difference engine' has to be
> expressed by programs that support screens. This is subtle (and I don't
> know if any product has done it yet). I think must one think in terms
> of two db's, although the db fragments on the side of the screen program
> would be different in some ways, for example, if the orders table
> weren't part of the screen view, then the foreign key constraint of the
> items table wouldn't necessarily apply. This is a practical outcome of
> the RM that I think from my limited knowledge of existing efforts that
> hasn't been explored very much.

I think so to - I wonder why? Received on Wed Jan 11 2006 - 08:59:25 CET