This page (revision-13) was last changed on 26-Nov-2021 10:22 by RForbes

This page was created on 26-Nov-2021 10:22 by Administrator

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
13 26-Nov-2021 10:22 1 KB RForbes to previous
12 26-Nov-2021 10:22 1 KB RForbes to previous | to last Foreign Ke ==> FOREIGN KEY
11 26-Nov-2021 10:22 1 KB RForbes to previous | to last Foreign Key ==> Foreign Ke
10 26-Nov-2021 10:22 1 KB RForbes to previous | to last
9 26-Nov-2021 10:22 1 KB RForbes to previous | to last
8 26-Nov-2021 10:22 1 KB RForbes to previous | to last FOREIGN KE ==> FOREIGN KEY
7 26-Nov-2021 10:22 1 KB RForbes to previous | to last Foreign key ==> FOREIGN KE
6 26-Nov-2021 10:22 1 KB Administrator to previous | to last
5 26-Nov-2021 10:22 1 KB Administrator to previous | to last
4 26-Nov-2021 10:22 1 KB Administrator to previous | to last
3 26-Nov-2021 10:22 1 KB Administrator to previous | to last
2 26-Nov-2021 10:22 2 bytes Administrator to previous | to last
1 26-Nov-2021 10:22 56 bytes Administrator to last

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 1 added one line
A foreign key is an [Data Base Construct] used to ensure referential integrity. A foreign key means that values in one table must also appear in another table.
At line 3 added 13 lines
The referenced table is called the parent table while the table with the foreign key is called the child table. The foreign key in the child table will generally reference a primary key in the parent table.
Each table in the ePersonality schema has a field called [ID] which uniquely identifies each record. Any linked tables will refer to this record, through this unique value using a foreign key.
for example,
The [P2K_CM_UNITS] table has a field [ID] which uniquely identifies a record.
The [P2K_CM_JOBS] table is linked to the units table through a foreign key link called [DUN_ID]. This link allows us to determine the unit that a job may be related to, by following the foreign key link. It also ensures that a job is not "orphaned" by having the unit record deleted.
Each foreign key link is also identified with an index and constraint name which allows us to determine the relationship that is in question. The [table alias] that is on each side of this parent/child relationship is used in the naming of the foreign key constraint.
In the example above the foreign key constraint name would be defined from DUN (the alias for the units table - the parent in this case) and DJB (the alias for the Jobs table - the child) thusly: __P2K_DJB_DUN_FK1__.