Re: 3vl 2vl and NULL

From: dawn <dawnwolthuis_at_gmail.com>
Date: 30 Jan 2006 14:01:29 -0800
Message-ID: <1138656826.828436.148540_at_g47g2000cwa.googlegroups.com>

Frank Hamersley wrote:
> 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.

Welcome back. UML was not the point, just a tool to show that the data model related to the front-end and that of the back-end are necessarily different if you use the RM for your DBMS modeling. If you use a two-valued-logic and non-1NF data model end-to-end for your software development, you need not suffer this mismatch.

>


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

To some extent, perhaps (somewhat similar to XML developers thinking in strings), but my reason in this case is that although you might cast to another type (even on the way in after testing for compatibility), all data input through a UI can be handled as a string, the empty string being one such. The string could be seen as the top object for data entry, with all other types inheriting from it. A number is string input that can be cast to a numeric type, for example. (I realize this might be heresy to some)

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

In my view data can be binary (some MIME-type) such as pictures or video, or it is strings, possibly cast to whatever else will bear it.

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

What are these "measurable gains" then? What do they measure? Who has done such measuring?

> On anecdotal terms however
> and relating to some of the commonly held (as far as I believe) precepts

Yes, there are some such that need fixin'

> of good IT such as independence (separation of logical and physical) and
> simplicity (some will dispute this of course)

I tend to want things simple for me (and those around me) in contrast to insisting everything be as simple as possible for the developers of my tools or for the tools themselves.

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

We are in agreement on that.

> [..]

>

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

>

> No pics, no pack drill!
>
> Cheers Frank.

Have a good one. --dawn Received on Mon Jan 30 2006 - 23:01:29 CET