Re: sql views for denomalizing

From: Lauri <lauri.pietarinen_at_a>
Date: Sun, 31 Jul 2005 04:52:41 GMT
Message-ID: <tOYGe.4$hq.2_at_read3.inet.fi>

dawn wrote:
> Since a major is an attribute of a student's program, rather than a
> student directly (they could be both an undergrad with one set of
> majors and graduate with another, for example), major would still be
> modeled in a separate physical "relation" but a virtual field pointing
> to this list of majors would make it look the same to the user as if
> the field were in the student relation (file).
>
>

>>and also a multivaled attribute inside Student
>>that listed the courses that student was taking. Please correct
>>or confirm.

>
>
> again, this would be a virtual field pointing to where the information
> about courses (likely associated with the term, for example) would be
> found. The "current" part would pull off today's date to find which
> terms were current, all behind the scenes as part of the virtual field
> logic.
>
>
Let me see if I have understood this correctly:

1. first the "DBA" creates the tables (or whatever they are called in Pick), more or less as he/she would if using an SQL DBMS
2. then the "DBA" creates virtual attributes, which, in effect, are references to certain other tables (or whatever they are called in Pick)
3. after this the developer/user can use these virtual attributes as if they belonged to the table. These virtual attributes would contain lists, if the referenced table had several rows per "master" row, as seems to be the case in your example
4. these virtual attributes are first class citizens in the query language, and in the case of lists, can be queried with the likes of "every" any "any"
5. if the developer/user needed a new viewpoint he/she would ask the DBA to create new virtual attributes

It would be interesting if you could provide the complete DDL (or whatever it is called in Pick) for your mini-example together with the queries.

regards,
Lauri Pietarinen Received on Sun Jul 31 2005 - 06:52:41 CEST