Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Relational vs. PICK/Object DBMS

Re: Relational vs. PICK/Object DBMS

From: Dan <>
Date: Sun, 25 Apr 2004 04:13:46 GMT
Message-ID: <_VGic.38649$>

"Albert D. Kallal" <> 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
> My answer is 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
> physical).
> The main "difference" between the relational approach, and the Multi
> 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"
> to the parent table. This process is eliminated for most tables (note I
> most!).
> While your link posted starts out with 4 tables, I would rather thought
> 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
> 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
> 4 tables, and that already defines a bunch of relations. That algorithm
> assumes we have a dictionary setup as a "tree" that realizes that we do in
> fact have 4 tables (in the give could certainly be "n"
> I would simply state that for each given key of man#, any repeating data
> 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?



[snip of interesting material]

> If you want, I can define the above data table..add a few records..and
> post a few queries..and their results if you wish..
> --
> Albert D. Kallal
> Edmonton, Alberta Canada
Received on Sat Apr 24 2004 - 23:13:46 CDT

Original text of this message