Black Box 4/BlackBox.cdr/database/datamage.arj/DOCS.ZIP/INDEXING.DOC

Text File | 1991-02-09 | 8.6 KB | 153 lines

                   THE DATAMAGE  file indexing instructions



DATAMAGE,  starting  with V: 3.1, has two indexing schemes.  At your  beck  and
call  are  FILE INDEXES and BINARY indexes.  The FILE indexes are  disk  files.
The BINARY indexes are the ORDER of the records in the current group.  The FILE
indexes  are  used  to find a record or records in the  datafile.   The  BINARY
indexes  can  be  used  to find records but that's not  really  what  they  do.
Searching  a  BINARY index, whether or not a match is found, takes you  to  the
place in the BROWSE display where your entries WOULD be in the current order.

FILE INDEXES:

The  terms:   FILE  INDEX,  UNIQUE INDEX and CROSS INDEX  are  defined  in  the
glossary of the instructions for the BASE program.  Briefly, a file index is  a
series of numeric values stored in a datafile on disk. These numbers  represent
the    contents   of  the  records  in  segments   defined   during    datafile
installation  as  indexed.  The purpose of a file index is to be able  to  find
records by entering the content of the indexed segment.

An indexed datafile is provided as a sample.  It is in the sub-directory of the
sample  datafile disk called CUSTOMER.  This datafile also illustrates the  use
of  the  POWRMAIL  program,  and contains the  names,  titles,  company  names,
addresses etc. of several concerns involved in the distribution of software for
the  P.C.   Start  the BASE program, and access this  datafile  in  the  normal
manner.

As  always,  press F4 to make a map of the file.  As you can see, four  of  the
data  segments  comprising  this file are indexed.  Segment  8  is  indexed  as
unique,  and  segments 1, 2, and 3 are cross-indexed.  Now, print  all  records
using  the I/O group.  You want to place segments 1, 2, 3, and 8 in  the  group
before  starting the printout.  Or, select alpha, target #3, title,  and  enter
president as your search string.  You'll still print enough records to test the
indexing.

To  access  the find a record sub-routine press F5.  After  giving  a  positive
response  to  the dialog box opt to search the unique index on  segment  eight,
phone  number.   Now, enter the phone number of any record on  your  list.   Be
certain that it is exactly correct before pressing return.  The record will  be
found  quickly, and displayed in the usual manner.  After you exit  the  record
display/update function the dialog box will ask you if that was the record  you
wanted to see, or if you would like to continue the search.

Now try the F5 routine again.  This time, use the index created for segment  3,
As a search value, enter PRESIDENT.

The  records that contain PRESIDENT in segment 3 will be displayed,  one  after
another.   After  each record you will be asked to select this  record,  or  to
continue the search.  Opt to continue the search until it is completed.   Then,
press 1 for a re-try.  Finally, opt to search the cross index.

You  may  choose to search any or all indexed fields to find a record,  in  any
combination you choose.

Now,  use your listing and select records in all available manners,  until  you
are  familiar with the indexing process.  Although we have made this a  simple,
menu-driven process, it is still quite difficult to comprehend for those new to
datafile operation.


DATABASE DESIGN CONSIDERATIONS:


When  designing  a  user-installed  datafile to  include  indexing,  many  more
considerations  must be made before declaring a segment as indexed.  Using  the
sample  as  an example, suppose we might have two people in the  same  company,
with  the  same phone number, in the file.  When we went to  enter  the  second
record containing the same phone number the unique index would be checked,  and
the record entry process would be aborted, due to the duplication, which is not
allowed in a segment defined as unique.

Try  it.  From the main menu, opt for record entry.  Enter garbage in  segments
1, 2, and three.  When you get to segment 8, try a phone number that appears in
one of the records on your listing.  The program refuses to write the record to
disk.   The same thing will happen if you attempt to update an existing  record
to  contain  a  phone number already present in another record.   This  can  be
irritating, but will make sure that no duplicates are entered.

The  indexed  segments are treated differently by the other programs  as  well.
The  BASE  program will refuse to write a code into the survivor group  if  the
target  segment is declared as indexed.

POWER  COPY will not change records in an indexed datafile if the target  field
is indexed.  Of course, POWER COPY will move data into a file that is  indexed,
and will move data into indexed fields in records created during the inter-file
update.  These new records will be checked for index violations, and aborted if
a duplication is found.

The indexing sub-routines ignore cases and spaces.  In other words, the values:
"ABC",  "abc"  and "A  B  C" all produce the same index value,  and  would  all
produce a match for each other.  So, if you fail to capitalize a letter in your
search  value,  or embed the wrong number of spaces between the  words  of  the
search value, the record will be found if you opt to ignore spacing.

Also ignored by the indexes are case and all characters not in the sets:   A-Z,
a-z  and 0-9.  So, opting to ignore case/spacing in a search, and entering  KA-
BOOM CHEMICALS INC will find a record containing KABOOM CHEMICALS, INC.

The  indexing does not work like a string sort; you must enter every  character
of your search value.  Searching for "JONES" will not produce a match for every
record containing the search string; only those containing the word "jones" (in
either or mixed case) and nothing else.

If you opt to use indexing to accomplish record selection, train your operators
well,  and  put  some  time and THOUGHT into your  indexing  scheme.   Try  and
consider  worst-case  scenarios and find ways around them before  defining  and
installing the datafile.

When backing up a datafile it is not necessary to backup the file FILEINDX.RAD.
You  will  save disk space by not doing so.  If it is necessary to  access  the
historic  datafile,  place  the  files on an empty disk,  and  start  the  BASE
program.  The index will be automatically computed and written on the disk.

BINARY INDEXES:

As  stated  above,  the BINARY INDEXES are based upon the ORDER  of  the  file.
There's  two ways, I suppose, to get your records into order.  One is to  enter
them  that way in the first place.  That won't last long unless it's  a  static
file.  New records happen, old ones croak, it gets out of order soon.

So  DATAMAGE  offers some VERY elaborate sorting capabilities.   Some  programs
have  a "MAKE INDEX" option, DATAMAGE has a sort routine.  The product of  that
routine is an order.  The order is the index.  And searching a BINARY index  is
to  find a place in the current order, as opposed to examining the  records  to
find a match for the search value.

The  BINARY INDEX feature of DATAMAGE allows for "shoot from the hip"  indexing
of any file based on the user-assigned record numbers, the content of a counter
field, or up to eight levels of disk data.  The BINARY INDEX feature is  almost
totally  automatic  in that it will update an active BINARY  index  in  MEMORY.
But, since DATAMAGE requires no associated disk file, it does not automatically
update MARKERS kept for the purpose of recording BINARY indexes.

In larger files the time required to sort the records makes the maintenance  of
a  disk  file  to  keep the order between  runs  attractive.   This  is  easily
accomplished, please read MAIN.DOC under the F-10 heading or the on-screen help
for the MARKER FILE function.

The  BINARY indexes offer a facility not found in the FILE indexes:   They  can
find  a  record  that's  not there.  If your entries  into  the  BINARY  search
function find no match you will go to the place in the file where they WOULD be
in  the  current  order.   The BINARY SEARCH is so  often  used  simply  to  go
somewhere in the BROWSE display that it does not enunciate a no-match.

After  doing  a BINARY search you go to the place in the BROWSE where  a  match
would  be.  The "top" two sort criterion are on the BROWSE screen, and a  touch
of  the return key displays the record.  It should be easy to determine if  you
found a match.  If it beeped and displayed an error message on a no-match  this
would,  no doubt, prove quite irritating when using the search to move  in  the
BROWSE display to a place in the current order.