Té said:
What is exactly does the table analyzer do? From my perspective it looks
as
if it breaks one table down into many tables. When I used it I noticed
the
fields on my new table read lookup to tbl.... Is there anyway to get rid
of
this?
Why would someone use this? Access is frying my brain!!!
The conceptual term for this is what we called data normalization. This is
likely the most important concept you'll learn as to how relational
databases are to be used to solve real world problems.
The reason why we often split things up into more then one table is for
example we might have a customer table. We then might have a list of
products they purchased over the years. It would be really silly to type the
customer name, phone number, address over and over again for each purchase
they make
eg:
CustomerName Phone Address HomePhone WorkPhone etc etc et c.
In the above long list of field names, we could also add the product, the
purchase price and the date of purchase. however, we would have to re-enter
the customer name + phone + address over and over. In a normalized design,
we would
use two tables:
tblCustomers and tblPurchases
In the above tblPurchases would be related back to customers..and thus for
each new purchase, I would NOT have to re-enter all of the customer
Information . And, if change a phone number, there is only ONE copy of the
phone number in the computer (in the ONE customer record).
Since the customer data is only entered once into the computer, then we only
ever have to maintain ONE COPY of the customer informaton. We will not have
the customer name and phone number repeated over and over in side of the
database. Therefore when we change the customer name, then all of the other
related tables to that ONE customer will use this new information. Hence,
the customer informaton will not be copied over and over.
The goal of true data normalization means that you only have one copy of any
piece of information in the computer that should never be copied more than
once. Of course pushing this concept of normalization too far means that
your code has to deal with more than one table. This often does increases
the difficulty of building the application for the software developer
**when** you are new to this concpet. However, that normalization results in
an application that will use up less developer time being spent over the
lifetime of the application.
So normalization is one of those things that is a lot like people who start
building a garage in their backyards, but they forget to make sure that the
foundation needs to be really good and straight. In a case of building an
garage if you don't get the foundation right, then you can build a whole
garage on top, and wind up having to tear it down because the foundation was
poorly done. (you waste a lot of time). The exact same concept applies to
data normalization, you can wind up building your whole application, but if
your data is not normalized, you'll wind up having to tear up much of your
work if you don't get this part of your application correct.
So normalizing your data is the one of the most important
skill or least one of the top skills that you need to have to really make
databases become your friend and not your enemy.
Here's some more articles that explain this concept for you:
ACC2002: Database Normalization Basics
http://support.microsoft.com/?id=283878
Database Normalization Tips by Luke Chung
http://www.fmsinc.com/tpapers/genaccess/databasenorm.html
Data Normalization Fundamentals by Luke Chung
http://www.fmsinc.com/tpapers/datanorm/index.html
324613 - Support WebCast: Database Normalization Basics
http://support.microsoft.com/?id=324613