Normalizing an onion

G

Guest

In situations where each record is one layer to an onion, and there are both
a number of layers to the onion and a number of onions in the box, how does
access best handle the relationships while keeping normalization in mind?

In truth what I'm working with is files and files within files. Each
"parent" File has been given an alphanumeric ID (A.01) and each "subfile" has
been given an extension of that ID (A.01.01) so I can see which files are at
the "top level" (A.01) and which are part of a "top level" parent file.

What I'm looking for is advice on organization of the tables as well as the
queries to have a high degree of normalization, to keep my IDs linked to each
file, and to ease future updates, additions or queries to the database.

Thoughts on approach, design, etc. would be appreciated!

The data in Field1 is the ID (Alphanumeric)
The data in Field2:Field22 is text

Field2 is the file_name of the "parent" while field3:field22 are the names
of files contained within the parent.

I have given the parent file a unique ID, but I also want to give the
"subfiles" unique IDs as well. In order to keep the relation between parent
and subfiles clear, I thought that the subdatasheet would make this possible.

So, I turned on the Subdatasheet so that the Master Field is Field2 and the
Child Field is Field3.

As I move the Field3:Field22 files into the subdata sheet, I received an
error message saying that I was not allowed to input duplicate information.
This occurred because some of the "subfiles" have the same title (e.g.,
"correspondence").

While my initial question was how do I get Access to accept duplicate
entries that I enter into the subdatasheets for different records, perhaps my
unwritten question is: Can this be done in a more efficient manner?

Lastly, I call the fields Field1, Field2, etc. as Field* is the default
title for fields in Access before you rename them. As the actual title
shouldn't have bearing on what I hope to achieve, I simply omitted them.
 
J

Joseph Meehan

sduffield2 said:
In situations where each record is one layer to an onion, and there
are both a number of layers to the onion and a number of onions in
the box, how does access best handle the relationships while keeping
normalization in mind?

In truth what I'm working with is files and files within files. Each
"parent" File has been given an alphanumeric ID (A.01) and each
"subfile" has been given an extension of that ID (A.01.01) so I can
see which files are at the "top level" (A.01) and which are part of a
"top level" parent file.

What I'm looking for is advice on organization of the tables as well
as the queries to have a high degree of normalization, to keep my IDs
linked to each file, and to ease future updates, additions or queries
to the database.

Thoughts on approach, design, etc. would be appreciated!

The data in Field1 is the ID (Alphanumeric)
The data in Field2:Field22 is text

Field2 is the file_name of the "parent" while field3:field22 are the
names of files contained within the parent.

I have given the parent file a unique ID, but I also want to give the
"subfiles" unique IDs as well. In order to keep the relation between
parent and subfiles clear, I thought that the subdatasheet would make
this possible.

So, I turned on the Subdatasheet so that the Master Field is Field2
and the Child Field is Field3.

As I move the Field3:Field22 files into the subdata sheet, I received
an error message saying that I was not allowed to input duplicate
information. This occurred because some of the "subfiles" have the
same title (e.g., "correspondence").

While my initial question was how do I get Access to accept duplicate
entries that I enter into the subdatasheets for different records,
perhaps my unwritten question is: Can this be done in a more
efficient manner?

Lastly, I call the fields Field1, Field2, etc. as Field* is the
default title for fields in Access before you rename them. As the
actual title shouldn't have bearing on what I hope to achieve, I
simply omitted them.


Access is both a science and an art. This is a question of the art of
database. There is not any one right answer. There are a number of wrong
answers, but many right ones as well. Each situation is different and the
more you know about Access and the data situation the better decisions you
can make.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top