Simple Database - computer parts, colours and materials

I'm trying to learn Access and databases at the moment, and so I thought as an exercise I'd make a very basic database of my laptop, it's parts, colour's of the parts and the materials of them (roughly)

So I have the information

Colours


Silver
Black

Part
MousePad
Screen
Computer Casing
Keyboard

Material
Metal
Rubber
Plastic

But I'm struggling with how to decide which of these would be a primary key, and I'm starting to wonder whether there's actually enough material here. I'm inclined to say that the primary key might be the laptop itself, but this database is just about the one laptop. The part? There can only be one part at a time, but then I don't know which of these parts I would say, or would I just say Part?

So I'm sure the confusion is fairly obvious, if anyone can shed any light onto said confusion or point me in a direction that'd be ace.

Thanks.

Consider these tables and fields:

tblParts
PartID
PartType (MousePad, Screen, Casing, Keyboard, etc)
PartColor
PartMaterial

tblColours
Colour (Silver, Black, White, etc)

tblMaterials
Material (Metal, Rubber, Plastic)

This simple of a structure really doesn't even need primary keys. The colours and materials tables each have very short list of values so I doubt duplication is a concern. Also, there are no other fields of information so by saving the text descriptors in tblParts there is no need to join tables in queries. Now, if you want to document the parts for more than one computer, that is a different matter.

Thanks June

It's purely for learning, there's no urgent 'point' in this table other than me trying to work a few things out.... So in your example have you used the 'Part ID' as the primary key..?

I was trying to pull information from the table into the form, but maybe I should have been trying to send information from the form to the table...

Thanks though, the tutorials section on this site's a bit advanced for me, if you know any basic reading places I'm all ears.

cross posted:
http://www.access-programmers.co.uk/...d.php?t=256591

Originally Posted by orange

cross posted:
http://www.access-programmers.co.uk/...d.php?t=256591

Yes it has been, I've only just learnt that it's such a faux pas, sorry about that. It's not really a problem with an objective solution though, more just asking opinion and if there's any ideas regarding learning sources around this.

Sorry though

No problem.
Here's a quote from an experienced user that puts it in perspective.

Anytime a poster starts a thread, then either solves it themselves or finds the answer elsewhere, etiquette dictates that they post the solution, so that others searching the same or similar questions can benefit.

Linq ;0)>

Wouldn't hurt to designate PartID as primary key but since it isn't used as a foreign key in another table, not really necessary.

Originally Posted by orange

No problem.
Here's a quote from an experienced user that puts it in perspective.

Yes

My problem was more with my own understanding rather than something objective like coding or such.

What I can say I have learnt (and may be to anyone learning..) is that there are some interesting resources on Rogers Access Library about design and mapping thing's out. Some of it hasn't really sunk in for me yet, but the informations useful. Like primary keys, I understand why a unique value is important for referencing and that but I don't really comprehend how primary / foreign keys are best assigned, and how they interact within a database. He (Roger from that site) references a book called Database design for mere mortals which I may look at, though I'm not sure if there's something more appropriate for my level or not.

1. how primary / foreign keys are best assigned
Establish relationships with Relationship builder and/or set Master/Child links in subform container control. This will cause primary key to automatically save as foreign key during data entry.

2. how they interact within a database
PK/FK fields are used to join tables in query so all associated information can be viewed, also used to synchronize related records in form/subform or report/subreport arrangements.