Re: 3vl 2vl and NULL

From: paul c <toledobythesea_at_oohay.ac>
Date: Wed, 11 Jan 2006 01:44:39 GMT
Message-ID: <bqZwf.178135$2k.152107@pd7tw1no>

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?

Not sure if you're asking me, but assuming that's so, I would say that 'screens' or displays (and really I'm talking here of OS facilities, not hardware) aren't capable of having a data model. 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. 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.

p Received on Tue Jan 10 2006 - 19:44:39 CST