Re: Views for denomalizing

<SNIP>

> I have always talked about relations in the "logical model" (which might
be
> an old term at this point) as being what we normalize in our model. Is
that
> correct?
>
> In the logical model, I model both base relations and derived relations
(aka
> views). I realize some people might narrow their model to only the base
> relations, at least at first, but this is legitimate, right?
>
> Then why isn't it appropriate to discuss the degree of normalization of
each
> of those relations (whether base or not)?

Dawn,

Normalization occurs at a logical level (note I did not say "the" logical level, as I am just distinguishing logical from physical, not getting into logical vs conceptual- IOW, let's say logical and conceptual are the same thing, and are different from physical, just for this discussion.). Normalization is obtained by working with functional dependencies (FDs). The relations that surface are a result of having determined the FDs among _all_ of the data in the mini-world (business domain of the data under consideration). Views are a physical construction and have nothing to do with normalization. So, you may wish to visualize it like this (working upside down here):

attributes
[apply FDs to get to the next level, revealing PKs in the process]: relations (entities and relationships - an ERD is often created here) [apply transformation rules* to the ERD to get to the next level] -----boundry between logical and physical---------- tables [by this time, you should de facto be in 3NF or greater] views [can achieve an _appearance_ of denormalization]

• There really are rules. One day I will post them- there are a small handful

Now, in reality, and after much experience, and working with familiar domains, one usually just skips right to creating tables. One often gets burned by doing this. Also, note that I said that views _can_ achieve an appearnce of denormization. They can be used for many things, but a discussion of normalization in relationship to views is not proper. As you can see, the two concepts are several layers apart. Remember, a view is nothing but a stored SQL statement- and the statement is theoretically running against a normalized database. You can think of it as an on-screen report (an over-simplification, but it helps the explanation).

IHTPAETI (I may have coined a new acronym)

><SNIP>.
>
> If you, Daniel, are not a user of any DBMS tools or APIs, then I can
> understand why you are missing my point. When developers in database
> companies are writing tools and API's for their DBMS products, it is the
> person who they see as their user that I am calling the DBMS user. Does
> that work for you?

An end user does not normally use an API, which is a programming tool. He uses the interface created with the API.

>
> >> A DBMS is a software application for a set of users -- the users I'm
> >> referring to are any who use the DBMS software directly. That would
> >> include any person or software issuing SQL commands, for example.
> >
> > But most RDBMS users are machines. Machines doing batch processing at
> > 2am. Most are printing billing invoices. Most are doing a lot of things
> > that do not involve human interaction. There are no "users."
>
> Who is coding to the API's -- those are users of the DBMS.

No, as explained above. Received on Fri Feb 04 2005 - 05:18:29 CET