Table Analyzer Wizard

[Guest]

Good Morning,
I intentionally designed one big single table with all the fields I need.
Approx. 6 or 7 fields.
Some fields like the Names column can be repeated with the same name in many
records.
I filled in the table with approx. 10 or 15 records as a demo test. Then ran
the Table Analyzer Wizard to see how it would react. But, it said there was
no reason to normalize the table into smaller tables.
Does the wizard only work on a certain size table/database?

This is my first official database which I think could use multiple
normalized tables.
I wanted to see what the wizard would do, so I could see how it set up
properties, lookup fields etc. in the background.
Does anybody have experience with this feature of Access?
I'm just learning.
Thanks,
Amy

 

[BruceM]

I'm not a big fan of the analyzer feature. Having said that, there may be
nothing wrong with your table. If a first name (or the full name, for that
matter) repeats, that is to be expected. It is not a violation of design
principles if several people are named Amy, or even if they are named Amy
Zee. This is not what is meant by duplicate data. Duplicate data would be
something like a company with several workgroups. One employee could be a
member of several groups. If the employee's name is in an Employee table,
you could link to that. If the employee's name appears in the rosters for
several groups, the rosters should link to that employee's name. If the
name ever changes, all of the rosters would reflect that change because they
are linked to the single employee record.
If you meant something else than what I imagine by your reference to the
Names column, please specify.

 

[Guest]

Thanks for answering my question and guiding me down the right road BruceM.
Actually there are more fields than just the Names field that has a lot of
repeated info. But I see now what you are saying. I thought any repeated
data was bad.
I'm going to go through my field list and restudy it. I'll probably print it
out here at the newsgroup and wait for any recommendations so I can
understand this better.
This is my first "real" database project.
Amy.

 

[BruceM]

Good idea to post the structure, and to be aware of repetition. Again,
difficulties may arise not when two people have the same name, but rather
when several records refer to the same person, especially those in related
tables, contain that person's name. That's where linking to a unique
identifier (Employee ID, for instance) comes in.
Beware of invariable rules. In my company a form contains an employee's
name. The paper form also contains that person's signature. If that
person's name changes, old records need to show the name of the person as it
appeared at the time the form was signed, not the new name. In that case I
need to store the name, not the ID number.