Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: More on lists and sets

Re: More on lists and sets

From: Brian Selzer <>
Date: Sat, 25 Mar 2006 19:08:26 GMT
Message-ID: <KygVf.8559$>

I think that there is a fundamental problem with the MV/NFNF mindset. There is often a one to many relationship between how information is stored and how it is presented. While it may be optimal in one case to present information in a list, there may be other cases where it is not. On the other hand, there is always one optimal way to store information: each proposition must exist in only one place. This includes not only propositions that are physically stored, but also those that can be derived. Either something is known, or it isn't, so it doesn't make logical sense to store it more than once. It may make sense to materialize views to improve performance for one application, or to cache NFNF representations in a middle tier to optimize access for another, but the underlying logical data model must be free from redundancy. Redundancy increases the amount of programming required to guarantee consistency, so while it may reduce the total code required to present information for one application, it increases the amount of code required for all others.

The problem with NFNF models is the introduction of redundancy and second order predicate logic. Issues that are solved through the application of higher normal forms reappear with the introduction of composite attributes. The predicate of a NFNF relation may include variables that range over subsets, which cannot be expressed using first order logic. I think that this makes it much more difficult to verify the correctness of the model.

"David Cressey" <> wrote in message news:jhxUf.5689$8G2.2014_at_trndny01...
> "Brian Selzer" <> wrote in message
> news:j%tUf.49721$
>> If order is unimportant, then transformation back and forth between a
>> list
>> and a bag is trivial.
> It's trivial in the sense that no non trivial information is lost. But
> it
> may not be non trivial in the sense of affecting programmer productivity.
> According to the MV enthusiasts, their data structure is more conducive to
> presenting data "the way people think". I'm not convinced, when it comes
> to
> the interface between the database and the programs that manipulate data.
> However, there is another context, where NFNF data is clearly easier on
> the
> eye than 1NF data.
> Here it is: It's a window with three frames inside it. The first frame
> is
> fixed, displaying the data that occurs once per entity. Each of the two
> remaining frames shows a scrolling list, for related data that can occur
> multiple times.
> I'm kind of sick of pizza right now, so here's my example:
> The window is of applicants for a job. The first subframe is for data
> like
> First Name, Last Name, SSN, etc. that occurs once per applicant.
> The first list is for skills the applicant possesses, with data about
> number of months of experience, and certification (yes or no). Each
> skill
> occupies a line in the frame. If there are more skills than fit in the
> frame, scrolling happens.
> The second list is for previous jobs the applicant has held. (Start date,
> end date, job title, etc.). There's one line for each job. Again, if
> the
> whole list won't fit in the frame, scrolling happens.
> If the applicant is still employed the last "end date" is left blank
> (Hah!
> Take THAT D&D!)
> Clearly the two lists can expand arbitrarily. (while the relationship
> between skills and previous employers might exist, it might not be
> relevant
> for this screen.)
> In this case, I'm interested in storing the data in relational tables
> (because of the power described by Codd Date & Darwen, etc), but I think a
> programmer is legitimately interested in viewing the data as if it were a
> hierarchy. (I'm treating HDM and MVDM as equivalent for purposes of this
> illustration).
> So I'm interested in a sublanguage that can SELECT the data using
> relational
> operators to join data from at least 3 tables, but can DELIVER the data
> to
> the program in NFNF (see Dawn's blog). That transfom is, as you
> pointed
> out, trivial from an information perspective.
> But it's not very easy from a programming perspective. And programmers
> would be more productive if it were easy.
> This is my version of "have your cake and eat it too". Mike Preece and
> others set forth the value of "the programmer can do anything he wants".
> Yeah sure, if the data is in working storage. Even if the data is in a
> private file that nobody else uses. But if it's in a "large, shared
> database" then you can't do anything you want, because that leads to
> chaos.
> The interests of all the stakeholders in the large shared database have to
> be balanced. The larger and more widely shard the database is, the
> larger
> the community of interests to be balanced.
> And that to me is the difference between a "file" and a "database" in a
> nutshell.
Received on Sat Mar 25 2006 - 13:08:26 CST

Original text of this message