Re: 3vl 2vl and NULL

From: Frank Hamersley <terabitemightbe_at_bigpond.com>
Date: Mon, 30 Jan 2006 03:42:10 GMT
Message-ID: <mWfDf.230762$V7.122558_at_news-server.bigpond.net.au>


dawn wrote:
> Frank Hamersley wrote:
>

>>dawn wrote:
>>
>>>Frank Hamersley wrote:
>>>
>>>>dawn wrote:
>>>>
>>>>>Frank Hamersley wrote:
>>>>
>>>>[....]
>>>>
>>>>>If the data model visualized on the screen has one instance of an ID
>>>>>and the SQL view backing that screen has many instances of this same ID
>>>>>value, then the data models are different.
>>>>
>>>>Are we talking about the model or manifestations of it (instances)?
>>>
>>>We are talking about the logical model itself, but perhaps using that
>>>term differently.  A logical model that is in first normal form is
>>>different from a model of that same data that is not.  They are not the
>>>same model simply because they model the same thing.  Trees, networks,
>>>and relations might all model the same data, but they are not the same
>>>model.  The model associated with a screen of data is not typically a
>>>no-repeating-groups relation as required if it were to be output
>>>directly from a SQL-92 view.
>>
>>You are presuming that visibility of all the data on the "screen" is
>>mandated.  Personally I have no such hang-ups*.

>
> 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.

G'day Dawn - just back from a break in South West region of WA - I can recommend it but leave your diet at home and be prepared to get salty!

On the UML stream, I have to admit my recent deployments (as measured in your BfB terms) I am situated in a very small team where documentation of this type is not required. Notwithstanding that I can accept that communication from designer to developer could be difficult if the UML were as you describe. BTW this has been the case since Adam but is not offered as an excuse.

> 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?

Isn't this what computers do for a crust! I'm not sure why the "strings" specifically are so interesting to you. I assume it is a Pick'ism to contemplate data in terms of strings? In my view data is simply data - f someone feels compelled to cast it to another form so be it, but it is not expected that the DBMS is forcing you to do so.

>>* see below.
>>>>[..]
>>>>
>>>>>>I think you have expressed most clearly the core of the problem
>>>>>>troubling you.  It seems you can't accommodate the SQL outcomes because
>>>>>>it doesn't have a "shape" that you are comfortable with.
>>>>>
>>>>>I'm actually quite comfortable with it, but I don't see an advantage to
>>>>>using it to the extreme typically employed with SQL-DBMS's.
>>>>
>>>>I'm missing something - what is the "extreme" bit?
>>>
>>>If there really is a reason to have data in base relations with no
>>>repeating groups, surely that requirement goes away with relations that
>>>are logical views of the data.  SQL permits views not to be in 2NF,
>>>3NF, BCNF, 4NF, ... but took this notion of no repeating groups to the
>>>extreme and requires it even in logical views of the data.
>>
>>As DC said I don't see any reason for exchange of information from the
>>DBMS to the Screen App to be exclusively 1NF in the strictest sense.  I
>>suspect you feel that "softness" weakens the process more so than the
>>2VL/MV no translation mantra holds.
>>
>>I disagree - there are measurable gains to be had in adopting the RM for
>>the storage engine that,

>
> Can you point me to some emperical data that indicates that? And even
> if that were the case, are there corresponding gains to making the RM

> the interface between dbms and humans (developers)?

I have no empirical data (for or against). On anecdotal terms however and relating to some of the commonly held (as far as I believe) precepts of good IT such as independence (separation of logical and physical) and simplicity (some will dispute this of course) are on offer. Sure, these are not necessarily unique to the RM, but I feel

>>IMO, outweighs any perceived cost of developing
>>and maintaining a dialect to transfer information from it to a
>>application.  In my view the 2VL/MV actually allows, nay encourages,
>>that "softness" to find its way into the repository, which in the wrong
>>hands is a Bad Thing tm.

>
> There are greater risks for some types of problems in one scenario and
> others in the other. I don't know how to go about getting emperical
> data about the quality of data and processes over time using one

> approach compared to another.

...which is why IT can't match (say) the medical sciences and the epidemiological approach they deploy to determine efficacy (even if its not foolproof at least there is a basis). IT as I have bemoaned oft before has barely achieved stone-age techniques let alone producing a guilded master craftsman or sanctionable professional.

[..]

> Without a picture, I just can't visualize it. Cheers! --dawn

No pics, no pack drill!

Cheers Frank. Received on Mon Jan 30 2006 - 04:42:10 CET

Original text of this message