Re: Relational vs. PICK/Object DBMS

"Dan" <guntermannxxx_at_verizon.com> wrote in message news:_VGic.38649$G_.4046_at_nwrddc02.gnilink.net...
> Hello Albert!
>
>
> 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.

Good question!

And, the answer is NO, could not do that. I mean, with sql, we would of course have a enforced relation to the child table of jobhistory. So, the sql system would not allow it..or we would have to turn off any kind of enforced integrity, and allow orphaned child records (this assuming I got your question right!).

> employee' (man#, name, birlhdate)
> jobhistory' (man#, jobdate, title) <---- we would have to allow man# to
be null/not required
> salaryhistory' (man#, jobdate, salarydate, salary)
> children' (man#, childname, birthyear)
>

In MV/pick, we have:

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

Looking at (jobdateH, title), it simply is NOT possible to enter that jobDateH, or Title without keyid of man# already existing. We are free to leave either jobdateH, and title empty..but we do fact requite that a record with a keyid of man# exist.

>
> Is it possible, given the preceding mv model, that I could do this with
the
> same schema?

So, no we can't (and, I would say that in a relational model..we would have to "break" the relation anyway).

>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

The above is a piece of cake..and in fact I could add that new field WHILE the system is live, and in use. That is fine (and, in most systems it is fine).

>, could you add the extra data value without having a correlating
> employee listed as the object upon which existence is dependent?

As mentioned..no. As the schemata is given...those child tables are in fact child tables..and don't work without the parent record. In a MV system, we don't call them child tables..but those fields belong to the man# record. However, lets assume we did know that in many cases that we would allow orphaned child records. In a MV system, we would have to make the decision to move that data out of the current table, and then use much the same concepts we use in a relational mode. We would get:

employess: man#, name, birlhdate, (jobID), (jobdate, salarydate, salary), (childname, birthyear).

jobhistory: jobID, jobdate, Title

In the above..we now have two MV tables..and thus we are now free to create jobhistory records without a corresponding parent record.

So, in a MV system, we do as a matter of coarse use more then one table when the design requires such needs. The "joins" that you need are in fact defined the in dictionary..and NOT in query language like sql does. So, once the join is defined in the dictionary, then those child fields would be available to the query processor.

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