Re: Relational vs. PICK/Object DBMS

"Albert D. Kallal" <kallal_at_msn.com> wrote in message news:KRhic.226504$Pk3.195528_at_pd7tw1no...
> 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).
>
Hello Albert!

Thank you for giving us, or at least me, some inkling as to how this would be modeled. A concrete example to consider is very beneficial.

I have a (probably trivial) question, however. This might be a contrived example, but bear with me. I'm interested in understanding how Pick would handle this particular situation.

If the business turned around and stated it needed to record job titles independent of whether it is associated with an employee and jobdate? A concrete example might be something like 'Outsourcing Manager', where no employee has been assigned the title yet.

Is it possible, given the preceding mv model, that I could do this with the same schema? Let's say someone comes and says we are adding a new job title and we want to add an additional description attribute of all current job titles, could you add the extra data value without having a correlating employee listed as the object upon which existence is dependent? And how about the additional description attribute?

Thanks,

Dan

[snip of interesting material]

>
> 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
>
>
Received on Sun Apr 25 2004 - 06:13:46 CEST