HP3000-L Archives

January 2002, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Steve Dirickson <[log in to unmask]>
Reply To:
Steve Dirickson <[log in to unmask]>
Date:
Sat, 19 Jan 2002 02:15:01 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (66 lines)
> I am quite familiar with SQL but new to IMAGE. One common
> data structuring technique in SQL is the use of a 'secondary
> index' on a table to provide fast access by an alternative
> access path from the primary index, as in ;
>
> create table employee (
>         empno           number (5),
>         name            char (30),
>         dept            char (4)
> )
> create unique index empix on employee (number);
> create index empdep on employee (dept);
>
> create table department (
>         dept            char (4),
>         depname char (30),
>         manager number (5)
> )
> create unique index deptix on department (dept);
>
> This allows all employees of a specific department to be
> retrieved efficiently.
>
> What is the best / recommended way to structure this data in
> IMAGE. If I have 2 master sets EMPLOYEE and DEPARTMENT I
> don't think I can make EMPLOYEE a detail of DEPARTMENT, so I
> must create a detail set say DEPTEMP which has items DEPT and
> EMPNO which is a detail of DEPARTMENT chained on DEPT and
> containing the employee number (or record number?) of the
> EMPLOYEE master.

The IMAGE equivalent isn't going to be that different from the
relational version: you'll have a 'department' set and an 'employee'
set. The difference lies in the way you link them together: instead of
creating an index on particular columns, you designate items within
the set as "search" items. Older IMAGE designs tended to use a lot of
manual master sets, but manual masters have become less popular as
limits eased and technology changed. In your case, you'd have
automatic master sets for 'dept' and 'empno', and detail--not
master--sets corresponding to your 'department' and 'employee' tables.
In lieu of creating an index, you designate employee..empno and
department..manager as search items linked to the 'empno' auto master,
and employee..dept and department..dept as search items linked to the
'dept' auto master. Detail sets can have up to 16 items designated as
search items, keyed to different master sets or to the same master set
in any combination.

Manual master sets can have only one key item, so they are less
flexible when the items defined by the set have more than one value
that you want to use for searching, grouping, etc. On the other hand,
if you only need to search by the single key item, they offer a slight
improvement in efficiency, and they guarantee both that the key values
are unique and that a valid master-set entry exists before you are
allowed to add records to linked detail sets.

In general, anywhere you would designate a key column in a relational
database, you'll be looking at a search item in a detail set for
IMAGE. If the relational table would have exactly one primary key
(i.e. never need a foreign key for any of the other columns), the
IMAGE equivalent could be a manual master set. But, if there's any
chance you'll ever need to search on any of the other fields, use a
detail linked to an auto master.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2