Help on Normalizaton

[CribbsStyle]

I'm new to access and just read about normalization. I'm creating a
Sports Card Manager application. My question is how would I normalize
my database. Right now I have one table labeled cards, with all of the
fields in it, like one big spreadsheet. Here are the fields...

id
Own/Want (Own/Want)
Sport (Baseball/Basketball/Football)
year
manufacturer
set
Player Name
Card #
serial #
forsale
saleprice
fortrade
description
cardtype (Base/Insert/Parallel/Other)
autographed (Yes/No)
gameused (Yes/No)
pressplate (Yes/No)
raceused (Yes/No)
rookie (Yes/No)
value
fimage

 

[Shaun]

For a good intro to design (including normalization), see
http://www.utexas.edu/its-archive/windows/database/datamodeling/index.html.

 

[John W. Vinson]

I'm new to access and just read about normalization. I'm creating a
Sports Card Manager application. My question is how would I normalize
my database. Right now I have one table labeled cards, with all of the
fields in it, like one big spreadsheet. Here are the fields...

id
Own/Want (Own/Want)
Sport (Baseball/Basketball/Football)
year
manufacturer
set
Player Name
Card #
serial #
forsale
saleprice
fortrade
description
cardtype (Base/Insert/Parallel/Other)
autographed (Yes/No)
gameused (Yes/No)
pressplate (Yes/No)
raceused (Yes/No)
rookie (Yes/No)
value
fimage

Aren't we discussing this in another group???

You need a Table for each type of Entity - real life person, thing, or event -
of importance to your application. I'd see the following entities here (there
may be more):

Cards
Sports (you might want to add soccer and hockey someday <g>)
Manufacturers
Players (each player will potentially have many cards)
Cardtypes

and perhaps Images, if you decide that you need to store multiple images for
each card - back and front perhaps.

Each type of Entity gets its own table. Your Cards table would then have
"foreign key" fields linked to the other entity tables - ManufacturerID,
PlayerID and so on.

John W. Vinson [MVP]