A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Database Design
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Two PK in a single table



 
 
Thread Tools Display Modes
  #1  
Old March 4th, 2005, 10:21 AM
Rasoul Khoshravan Azar
external usenet poster
 
Posts: n/a
Default Two PK in a single table

Is it possible to have two Primary Key in a single Table?

Why do I ask this question?

After many misdesigns, I understand that it is a mistake to join one PK of a
single table to two different tables. This design format is totally wrong
and never works (if I am not right with this conclusion, please correct me).
As a solution, I am thinking to put to PK in a single table so to use each,
for separate join.
My DB is as follows:
This DB is aimed for the procedure of getting a ProformaInvoice(PI) from a
seller, opening a Letter of Credit (LC) in a bank and shipment of
commodities.

ProformaInvoiceTbl
PIID (PK)
SellerID (a foreign key)
PInumber (set as PK)
.... (other fields)

CommodityTbl
CommodityID (PK)
PIID (FK from ProformaInvoiceTbl)
.... (other fields)

BudgetAssignerTbl
AssignerID (PK)
PInumber (FK from ProformaInvoiceTbl)
.... (other fields)

TIA, Rasoul Khoshravan Azar

  #2  
Old March 4th, 2005, 12:50 PM
Van T. Dinh
external usenet poster
 
Posts: n/a
Default

No, you can only have _one_ Primary Key per Table. You can include up to 10
Fields as a composite PK (but this isn't the situation you described).

I am not sure of your description but there are millions of databases out
there happily churning along with one PK per Table.

--
HTH
Van T. Dinh
MVP (Access)




"Rasoul Khoshravan Azar" wrote in message
...
Is it possible to have two Primary Key in a single Table?

Why do I ask this question?

After many misdesigns, I understand that it is a mistake to join one PK of

a
single table to two different tables. This design format is totally wrong
and never works (if I am not right with this conclusion, please correct

me).
As a solution, I am thinking to put to PK in a single table so to use

each,
for separate join.
My DB is as follows:
This DB is aimed for the procedure of getting a ProformaInvoice(PI) from a
seller, opening a Letter of Credit (LC) in a bank and shipment of
commodities.

ProformaInvoiceTbl
PIID (PK)
SellerID (a foreign key)
PInumber (set as PK)
... (other fields)

CommodityTbl
CommodityID (PK)
PIID (FK from ProformaInvoiceTbl)
... (other fields)

BudgetAssignerTbl
AssignerID (PK)
PInumber (FK from ProformaInvoiceTbl)
... (other fields)

TIA, Rasoul Khoshravan Azar



  #3  
Old March 4th, 2005, 01:03 PM
Nikos Yannacopoulos
external usenet poster
 
Posts: n/a
Default

Rasoul,

There is absolutely no reason why you can't have a table's PK as a
foreign key in several others; on the contrary, it is common practice.

A table can only have *one* PK; this may be a single field or a
combination of several fields, but even the latter comprise a single PK.
You may add more indexes on other fields as required.

In your particular case, at least if I understand it correctly, I have
some comments on the design:
Table ProformaInvoiceTbl is fine, but needs to be complemented with a
PIDetailsTbl, for the commodities (line items) in each proforma. That
table should be separate from CommodityTbl, which should store commodity
data such as CommodityID (PK), Description, Unit of Measure, Weight,
whatever... The CommodityID must be a foreign key in PIDetailsTbl, which
would look something like:

PIDetailsTbl
PIDID (PK, autonumber)
PIID (FK from ProformaInvoiceTbl)
CommodityID (FK from CommodityTbl)
Quantity
UnitPrice (or line item value)
....

Likewise, you should have a table with BudgetAssigners, whose PK is a FK
in your ProformaInvoiceTbl.

The idea behind both proposals is that master data (commodities and
Budget Assigners) is separated from document data, and no single piece
of information is duplicated (data normalization).

HTH,
Nikos

Rasoul Khoshravan Azar wrote:
Is it possible to have two Primary Key in a single Table?

Why do I ask this question?

After many misdesigns, I understand that it is a mistake to join one PK of a
single table to two different tables. This design format is totally wrong
and never works (if I am not right with this conclusion, please correct me).
As a solution, I am thinking to put to PK in a single table so to use each,
for separate join.
My DB is as follows:
This DB is aimed for the procedure of getting a ProformaInvoice(PI) from a
seller, opening a Letter of Credit (LC) in a bank and shipment of
commodities.

ProformaInvoiceTbl
PIID (PK)
SellerID (a foreign key)
PInumber (set as PK)
... (other fields)

CommodityTbl
CommodityID (PK)
PIID (FK from ProformaInvoiceTbl)
... (other fields)

BudgetAssignerTbl
AssignerID (PK)
PInumber (FK from ProformaInvoiceTbl)
... (other fields)

TIA, Rasoul Khoshravan Azar

  #4  
Old March 4th, 2005, 01:21 PM
Jamie Collins
external usenet poster
 
Posts: n/a
Default

Van T. Dinh wrote:
No, you can only have _one_ Primary Key per Table. You can include

up to 10
Fields as a composite PK (but this isn't the situation you

described).

You may have many keys in a single table. Don't be put off by having to
choose one as the PRIMARY key. It may have special meaning to the
database *product* but not for current relational theory.

Jamie.

--

  #5  
Old March 4th, 2005, 06:12 PM
Rasoul Khoshravan Azar
external usenet poster
 
Posts: n/a
Default

Dear Van
Thanks for your reply.You mentioned:

You can include up to 10 Fields as a composite PK (but this isn't the
situation you described).

By composite PK, do you mean one PK and Indexes?
I counldn't understand you completely by *composite* PK.
If possible please give some explanation

Rasoul Khoshravan

  #6  
Old March 4th, 2005, 07:09 PM
Tim Ferguson
external usenet poster
 
Posts: n/a
Default

"Rasoul Khoshravan Azar" wrote in
:

After many misdesigns, I understand that it is a mistake to join one
PK of a single table to two different tables. This design format is
totally wrong and never works (if I am not right with this conclusion,
please correct me).


As we say on this side of the Atlantic: that is a load of old cobblers.
There is absolutely no reason not to use several tables to point at the
(one) PK of one table. What problem do you think you see as a result?

CommodityTbl
CommodityID (PK)
PIID (FK from ProformaInvoiceTbl)
... (other fields)

BudgetAssignerTbl
AssignerID (PK)
PInumber (FK from ProformaInvoiceTbl)
... (other fields)


No: both of these FKs should be referencing whatever you use as the PK of
the ProformaInvoices table. Are you getting in a fix because there is
some kind of relationship between Commodities and BudgetAssigners?

ProformaInvoiceTbl
PIID (PK)
SellerID (a foreign key)
PInumber (set as PK)
... (other fields)


No: get rid of one of these...


HTH


Tim F

  #7  
Old March 5th, 2005, 09:26 PM
Van T. Dinh
external usenet poster
 
Posts: n/a
Default

You can include up to 10 Fields in a _single_ PrimaryKey. The PrimaryKey is
_always_ uniquely indexed. You can, of course, have other indices (unique
and non-unique) in the same Table.

Check Access Help (or any Database book) on Primary Key as it is explained
fairly well in Help..

--
HTH
Van T. Dinh
MVP (Access)




"Rasoul Khoshravan Azar" wrote in message
...
Dear Van
Thanks for your reply.You mentioned:

You can include up to 10 Fields as a composite PK (but this isn't the
situation you described).

By composite PK, do you mean one PK and Indexes?
I counldn't understand you completely by *composite* PK.
If possible please give some explanation

Rasoul Khoshravan



  #8  
Old March 6th, 2005, 03:17 PM
Chris2
external usenet poster
 
Posts: n/a
Default


"Rasoul Khoshravan Azar" wrote in message
...
Is it possible to have two Primary Key in a single Table?


Rasoul Khoshravan Azar,

As many others have already pointed out, the answer is no.

Definition of PK: "A Primary Key is the column, or combination of
columns (up to 10 columns in MS Access), that *uniquely* defines a
row." There can never be more than one.



Why do I ask this question?

After many misdesigns, I understand that it is a mistake to join one

PK of a
single table to two different tables. This design format is totally

wrong
and never works (if I am not right with this conclusion, please

correct me).
As a solution, I am thinking to put to PK in a single table so to

use each,
for separate join.


I'm not sure exactly what you mean here.

"JOIN" refers to running Queries. If your CPU can tolerate the
workload, you can run a query that has a JOIN of one Table's PK
against *many* other Tables (as long as the PK entity from the first
Table is found in the other Tables, of course).

If you mean "establish a relationship" (i.e. in the Relationships
window), then many Tables can reference the PK of another table via
Foreign Keys.




My DB is as follows:
This DB is aimed for the procedure of getting a ProformaInvoice(PI)

from a
seller, opening a Letter of Credit (LC) in a bank and shipment of
commodities.

ProformaInvoiceTbl
PIID (PK)
SellerID (a foreign key)
PInumber (set as PK)
... (other fields)


Did MS Access allow you to create the above Table?


Sincerely,

Chris O.


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Design help, please SillySally Using Forms 27 March 6th, 2005 05:11 AM
unable to repair inobox Sudheer Mumbai General Discussion 1 February 20th, 2005 12:55 PM
Update Tables using forms achett Using Forms 5 January 28th, 2005 01:25 AM
Table Wizard Does Not Set Relationship if Foreign Key and Primary Key Name Do Not Match Exactly in Case. HDW Database Design 3 October 16th, 2004 03:42 AM
Complicated Databse w/many relationships Søren Database Design 7 July 13th, 2004 05:41 AM


All times are GMT +1. The time now is 10:22 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.