Re: Normalization and DBMS

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Tue, 11 May 2004 17:11:24 -0500
Message-ID: <c7rj2t$vsd$1_at_news.netins.net>


"Paul" <paul_at_test.com> wrote in message news:GLboc.3288$NK4.248974_at_stones.force9.net...
> Dawn M. Wolthuis wrote:
> > If you use Date's terminology, you need GROUP and UNGROUP operators
> > in your language. This could also be NEST and UNNEST. The language
> > used with PICK, for example, reads easier than SQL and includes such
> > language as "WITH EVERY" so you get
> >
> > LIST STUDENTS WITH EVERY MAJOR <> "MATH"
> >
> > Did that answer the question? --dawn
>
> Suppose there is some extra information about each "Major", maybe the
> name of the person in charge of it or something.
>
> In the relational model there would be a separate relation to hold the
> majors, so we'd just have extra columns there.
>
> We'd have a "students" relation with a many-to-many relationship to a
> "majors" relation, and a "student-major" relation to resolve this
> many-to-many relationship.
>
> How would this be done in Pick?

A nested table can have any number of columns as well. A "nested table" can be thought of as a table that is a child table of the parent.

> Are the entries in multi-valued fields always the full text, or are they
> ever id numbers that correspond to a different file? e.g suppose you had
> 1=MATH, 2=ENGLISH, 3=PHYSICS. Would you just store the numbers 1,2,3 in
> the multivalued "major" column and have a separate file for the lookups?
> How would the query be written then in Pick?

"Return links" are often in MultiValue fields -- they are lists of foreign keys. Yes, you still work to remove redundancy -- it is not the same as an OLAP cube. It can be used like an OLAP cube with all such repetitions being virtual fields, however. --dawn Received on Wed May 12 2004 - 00:11:24 CEST

Original text of this message