Re: Can we solve this -- NFNF and non-1NF at Loggerheads

"Dan" <guntermann_at_verizon.net> wrote in message news:1107817027.196841.324050_at_g14g2000cwa.googlegroups.com...
> "I am not certain what "not further decomposable by the database"
> means. It
> rings of implementation, which must be avoided completely in this
> discussion, as the implementation level, as you know, is not considered
>
> during the logical design."
>
> Well, Codd rarely talked in terms of implementation, but perhaps. I
> personally think he was talking in terms of the relational model since
> that was the context he raised his points.
>
> You raise a good point about RVA's or MVA's not being accepted, but I
> think there are cases where the RM doesn't or can't know if RVA's or
> MVA's are being accepted, and thus you I want to make sure you
> understand my point.
>
> I'll try to phrase it differently. Imagine an implementation that
> allows for the type BLOB. Now imagine within some given BLOB instance
> there exists a binary form of nested relations that some application
> understands (perhaps a modular processing element attached to the
> DBMS). The relational DBMS won't know this and has little capability
> in deciphering the contents for query optimization, etc. unless special
> operators act on that type in some way that results in materializing a
> relation in its classic sense.
>
> My objective in raising this example is that there could exist RVAs and
> MVAs that have structured meaning for something outside the domain of
> the RM DBMS, but structure and meaning is hidden from the relational
> model itself. In fact, contents of these BLOBS might be recursively
> decomposable in some relational fashion, but these internal semantics
> and predicates don't exist according to the DBMS. It is only concerned
> with equality of value and other BLOB type operators.
>
> In such cases, I can see how the classic definition of RVA and MVAs
> could within a database without affecting RM in its classic 1NF sense.
> In other words, orthogonality of type and the RM is left intact and it
> still conforms to the definition given by Elmasri and Navathe.
>
> Now, if asking the question of whether doing such things is good data
> management or good modeling technique, I'm inclined to say no vrey
> strongly. But theoretically, I don't see a problem with saying that
> MVA's and RVA's might exist as encapsulated data elements, but RM only
> treats them as a scalar (or atomic) type within which they are
> encapsulated.
>
> - Dan
>

They do exist as encapsultaed data elements, but you are comingling the Relational Model and an implementation. When modeling the data (in the Relational Model world), one sticks to the rules of normalization. Now, lets use Oracle as an implementation example. Naturally, it supports (as much as any product does), most of the notions of the Realtional Model. It also supports other models (like the NFNF model we are talking about). It supports it using two different structures: varrays (variable arrays) and nested tables. You can even use the relationally-modeled stuff together with the NFNF-modeled stuff, but that doesn't make the NFNF stuff normalized. It also supports XML structures now. they're not normalized, either.

Just because you can model something relationally, and then go off of that model during implementation, it does not make the non-relational items relational. You no longer have a normalized database, that's all. It's not good or bad, it's just (hopefully) appropriate for what you need to do. Received on Tue Feb 08 2005 - 01:54:29 CET