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 changed 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.
A foreign key is a Data Base concept used to ensure [referential integrity|REFERENTIAL INTEGRITY]. A foreign key means that values in one table must also appear in another table.
At line 5 changed one line
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.
Each table in the application 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.
At line 10 removed one line
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.
At line 12 changed one line
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.
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.
At line 14 changed one line
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__.
We can know this as the [alias|TABLE_ALIAS] __DUN__ is the alias used for P2K_CM_UNITS. Table Aliases are identified in the [IMTD] screen or in the table [P2K_AM_TABLE_DETAILS], and may also be seen on the [ERD] pages.
At line 15 added 9 lines
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|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 DJB (the alias for the Jobs table - the child table) and DUN (the alias for the units table - the parent table) thusly: __P2K_DJB_DUN_FK1__.
----
![Notes|Edit:Internal.FOREIGN+KEY]
[{InsertPage page='Internal.FOREIGN+KEY' default='Click to create a new notes page'}]