On 16 Jul 98 at 1:50, Andrew Williams wrote:

> I'm fairly computer-savy but databases are one thing I've not
> worked with much. I would like to set up four databases in MS
> Access 95. I would like one to list my comic book collection, which
> I could cross-index with want list of comics I don't have. I would
> also like to set up two other unrelated databases:  one to index
> articles from computer magazines, and one to organize basic
> customer information for my small, in-home business. Any help,
> instructions, or tips on getting these started would be greatly
> appreciated.

  The subject really calls for a book rather than an email message.
The most suitable thing I see on my shelves is "An Introduction to
Database Systems" by C.J. Date, 6th edition.  What you really need,
though, isn't so much an introduction to database SYSTEMS as to
database DESIGN -- and the best source I know of for that is "years
of experience".  Hmmm.

  A database consists of one or more TABLES, and some supporting
structures.  A table consists of RECORDS; each record consists of
FIELDS.  The database system provides a way for you to define the
fields of a given table, with names and type information.  The tricky
part is that if you change your mind about this structure after
you've added some rows of data, you may or may not be able to change
the structure.  [Often you can add additional fields, but you may not
be able to change the existing ones.]
  Once you've built a table, the system will let you create INDEXES.
These enable quick lookup of items in the table, based on the fields
used in the index -- the KEYS.

  Now suppose that you wanted to find every comic book in your
collection in which Iron Man appeared.  Obviously, he'd be in
practically every issue of Iron Man, and many of The Avengers, but
what about that appearance in Spiderman?
  The obvious/simple/wrong way to handle this is to add fields to
each comic book's record to hold names of "guest stars".  Unused
fields, though, waste space, while you're almost certain to run into
cases where you need more than you've added.
  The better way to handle this is to create two more tables.[*]  One
lists characters, and perhaps aliases.  [Decide how to handle Henry
Pym....]  Each character is also given an identifier in this table.
[You can define a numeric field in Access that will get incremented
as each record is created, giving you an automatic "serial number".]
  Define a third table, then, with two fields -- the ID of a
particular comic book issue, and the ID of a character who appears in
it.  So for each issue, there are a group of records which link to
character records; each character record is linked by zero or more
records back to issues in which they appear.  [This is a many-to-many
relationship.  Note that while you probably don't have many issues in
which no characters appear (!), you might have sold everything you
ever owned with She-Hulk in it -- so there are no link records for
her at the moment, but she's still in the character table in case she
shows up in a new acquisition.

[*]  This is one of several kinds of NORMALIZATION, restructuring a
database into tables to optimize speed and size and integrity.
  "Databased Advisor" magazine used to offer, as a dubscription
premium, a wall chart showing five different kinds of normalization.
That may still be available.

David G