Re: Relational vs. PICK/Object DBMS

We have the issues of logical view, and the physical view.

However, the question is can we apply the rules for normalization in that link to a MV system?

> By "the normalisation algorithm" I mean the algorithm
> described in http://www.acm.org/classics/nov95/s1p4.html

My answer is yes...you can. However, since the system works a little different, then the approach to doing this is slightly different also. However, once done, you CAN VIEW the result data in the SAME logical view that a sql/relational system results in. (note I said logical view..and not physical).

The main "difference" between the relational approach, and the Multi valued approach for normalizing is that the child tables in the MV system don't need a key, or what is typical a foreign key field defined to "relate" back to the parent table. This process is eliminated for most tables (note I said most!).

While your link posted starts out with 4 tables, I would rather thought the process of normalizing starts with one big table of UN-normalized data. I kind think that the example should then go through the process of breaking out the repeating data to 4 tables.

However, as I mentioned..I do like the example, and I can go through the process of how this normalizing applies to a MV system.

The model in that link is:

employee' (man#, name, birlhdate)
jobhistory' (man#, jobdate, title)
salaryhistory' (man#, jobdate, salarydate, salary) children' (man#, childname, birthyear)

In a mv system, the idea of simply moving repeating data to another table is actually what we call a "controlling and dependent set" of fields. So, in mv, we start out with a table like:

employee(man#,name,birlhdate,jobdateH,title,jobdate,salarydate,salary, childname, birthyear).

The problem with that "algorithm" shown is that we already started out with 4 tables, and that already defines a bunch of relations. That algorithm also assumes we have a dictionary setup as a "tree" that realizes that we do in fact have 4 tables (in the give example...it could certainly be "n" tables).

I would simply state that for each given key of man#, any repeating data is to be setup as a controlling and dependent set of fields. We get:

employess man#, name, birlhdate, (jobdateH, title), (jobdate, salarydate, salary), (childname, birthyear).

To setup those controlling and dependent fields in a MV system cannot be done by the query language, or ddl. However, you do make this definition in the dictionary). The tools to set this up vary from vendor to vendor..but I will say that the resulting dictionary defs is the same among vendors I used. I simply put brackets around the sets of fields in the dictionary to show which sets of fields would be defined as controlling, and dependent for this discussion.

I see nothing in the sense that would prevent the conceptual idea of normalizing the data in MV land. The main difference is that deleting, or adding those child records (dependent field sets in MV) does NOT requite the code system to insert that key value (man# in the example). Further, it also means that integrity is defined by default..since in a mv system, you cannot add those dependent sets of fields without writing out the WHOLE data set. I should also state that most MV vendors support sql now. Thus, a series of sql mapping statements could break out the above into a logical view that sql would give you (and you can use sql to work on the data). However, the "aql" (MV query) languages is much easer, since ewe never have to conceptually "join" the data in the child "sets" of fields.

If you want, I can define the above data table..add a few records..and then post a few queries..and their results if you wish..

--
Albert D. Kallal
Edmonton, Alberta Canada
pleasenonoSpamKallal_at_msn.com
http://www.attcanada.net/~kallal.msn