Two PK in a single table

[Rasoul Khoshravan Azar]

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

 

[Van T. Dinh]

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.

 

[Nikos Yannacopoulos]

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

 

[Jamie Collins]

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.

--

 

[Rasoul Khoshravan Azar]

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

 

[Tim Ferguson]

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

 

[Van T. Dinh]

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..

 

[Chris2]

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.