Very close. A PK cannot be repeated, else it isn't primary at all. You could use an autonumber PK as OrderDtlID (order detail id) because that's what this is - details pertaining to an order. Thus you'd need an orders table for the parent data. Some would suggest that your OrderID field be named OrderID_FK or something like that, to denote that this field is a primary key somewhere else. With this sort of setup, you would have one order id to many order detail rows. Can you see why you would not do this for pricing?
As long as you're learning stuff...
Normalization is paramount. Diagramming maybe not so much for some people.
Normalization Parts I, II, III, IV, and V
http://rogersaccessblog.blogspot.ca/...on-part-i.html
and/or
http://holowczak.com/database-normalization/
Entity-Relationship Diagramming: Part I, II, III and IV
http://rogersaccessblog.blogspot.ca/...ng-part-i.html
How do I Create an Application in Microsoft Access?
http://rogersaccessblog.blogspot.ca/...cation-in.html
Important for success:
One source about how to name things - http://access.mvps.org/access/general/gen0012.htm
What not to use in names - http://allenbrowne.com/AppIssueBadWord.html
About Auto Numbers
- http://www.utteraccess.com/wiki/Autonumbers
- http://access.mvps.org/access/general/gen0025.htm
The evils of lookup fields - http://access.mvps.org/access/lookupfields.htm
Table and PK design tips - http://www.fmsinc.com/free/newtips/primarykey.asp
About calculated table fields - http://allenbrowne.com/casu-14.html
There are tons of other sites, some with videos.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.