This page (revision-40) was last changed on 26-Nov-2021 10:22 by Karen Parrott

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
40 26-Nov-2021 10:22 11 KB Karen Parrott to previous
39 26-Nov-2021 10:22 11 KB Karen Parrott to previous | to last
38 26-Nov-2021 10:22 11 KB Karen Parrott to previous | to last
37 26-Nov-2021 10:22 11 KB Karen Parrott to previous | to last
36 26-Nov-2021 10:22 11 KB Karen Parrott to previous | to last
35 26-Nov-2021 10:22 11 KB rforbes to previous | to last
34 26-Nov-2021 10:22 11 KB jmyers to previous | to last
33 26-Nov-2021 10:22 11 KB jmyers to previous | to last
32 26-Nov-2021 10:22 11 KB jmyers to previous | to last
31 26-Nov-2021 10:22 11 KB RForbes to previous | to last
30 26-Nov-2021 10:22 11 KB RForbes to previous | to last
29 26-Nov-2021 10:22 11 KB RForbes to previous | to last
28 26-Nov-2021 10:22 11 KB RForbes to previous | to last
27 26-Nov-2021 10:22 11 KB RForbes to previous | to last
26 26-Nov-2021 10:22 11 KB RForbes to previous | to last
25 26-Nov-2021 10:22 11 KB RForbes to previous | to last
24 26-Nov-2021 10:22 11 KB JMyers to previous | to last NAMING CONVENTION ==> NAMING CONVENTION AND STANDARDS
23 26-Nov-2021 10:22 11 KB RForbes to previous | to last
22 26-Nov-2021 10:22 10 KB RForbes to previous | to last
21 26-Nov-2021 10:22 10 KB JEscott to previous | to last

Page References

Incoming links Outgoing links
ERD
ERD

Version management

Difference between version and

At line 13 added 5 lines
!Fields
* Primary key identified with the # symbol
* Mandatory item identified with the * symbol
* Optional item identified with the O symbol
The primary key is always labeled as ‘ID’, there can be ONLY one primary key in each table
At line 19 added 3 lines
!Shaded Tables
Sometimes in an ERD, a table will appear with a shaded background.
The shaded background indicates that the table is [date sensitive]. These tables will always have Effective (date) and Expiry (date) columns, although not shown on the ERD.
At line 23 added one line
The shading will appear grey on a black and white printout; however, it may appear yellow if the ERD is brought up on a computer.
At line 25 added 89 lines
!Bold Box
A table may also appear on an ERD with a bold border. This border indicates that the information in this table is provided as part of the [seed data].
!Dotted Line Within a Box
Occasionally, an ERD will display a box that will hold minimal information and contain a dotted line
This line indicates that the table is explained in detail in another ERD within the same module.
!Italicized Text Within a Box
The ERD’s also display boxes that hold only the table name and alias in italicized text. This indicates that the table is explained in detail in a different module's ERD.
!Lines
Solid Line Vs. Broken Line
The connecting lines between tables will be either dotted or a combination of solid and dotted lines. When reading a connecting line, you will notice many instances where a portion of the line is solid and a portion is dotted.
The solid line indicates that the Parent table (EID) is MANDATORY for the Dependant table (ECT). This means that the Parent table must be filled BEFORE the Dependant table can be completed. A broken line indicates that the Dependant table (ECT) is OPTIONAL for the Parent table (EID). This means that the Parent table can be completed WITHOUT the Dependant table having been filled.
If the connecting line between the tables is entirely dotted, the tables are optional for each other. This means that either table may be filled before the other.
!Written Description
In addition to the connecting lines, there are also written descriptions of the relationships between the tables. These descriptions will provide a more in-depth explanation of the relationship.
* The wording running along the TOP part of the line describes the relationship of the left hand table to the right hand table. (e.g. ‘Identity is known by the Alias’)
* The wording running along the BOTTOM part of the line describes the relationship of the right hand table to the left hand table. (e.g. ‘Alias is another name for the Identity’)
In the example shown above, the relationship between Identity (EID) and Alias (EAL), should be read as such:
The individual defined in EID is ‘KNOWN BY’ the alias in EAL.
The alias defined in EAL is ‘ANOTHER NAME FOR’ the individual in EID.
!Parent / Dependent Relationship
Another feature of the connecting lines is the end connections, circled in the diagram below.
Reading from left to right, we can see that the connection is a ‘One to Many’ relationship.
In this instance, the line starts as a single line at the Entity table and ends in many lines at the Unit table. This means that the entity may have many units associated with it, however, the unit cannot belong to more than one entity. Another way this can be expressed is that the Entity table is the PARENT of the Unit table and the Unit table is the DEPENDANT of the Entity table.
There can be a situation where two tables are parents to each other, which will be explained further on in this manual.
!Two Lines
Occasionally the tables will have two lines between them. There are two different scenarios for this type of relationships
__Parent/Dependant Relationship__
In the first scenario, one table is the parent with two lines moving towards a dependant table.
*** PICTURE ***
In this particular case, the Contact table holds keys to identify the contact’s physical address and mailing address. The two lines originating from the State/Province table indicate that the Contact table will need to use the state/province information on two separate occasions (location and mailing addresses) even though the State/Province information is only given once for each occasion.
The ‘One to Many’ nature of the lines originating from the State/Province table indicates that it is the PARENT to the Contact table. This means that while the state/province information can be applied to many contacts, each contact record, however, can use this data only twice, once for location and once for the mailing address.
__Parent/Parent Relationship__
The second scenario for a two-line relationship between tables is when tables are parents to each other.
*** PICTURE ***
The example above shows that the two lines between the tables express that the User table is the parent of the Identity table AND that the Identity table is the parent of the User table; the tables are parents to each other.
This simply means that the user identity may have many employee identities attached to it and that the user identity may have may employee identities attached to it. In this case, both tables will have foreign keys for the other table.
!Bold Line
A bold line between two tables indicates that if you delete the record in the parent table, the associated record in the dependant table will be deleted. This is know as a Cascade Delete.
***PICTURE ***
In this example, if the assignment record were deleted, the associated assignment detail record would also be deleted automatically.
!Curved Line
A final line format is the curved line that originates and ends at the same table. This represents a self-referencing foreign key.
*** PICTURE ***
In the example above, we can see that the Entity table has a key (DEN_ID) that refers back to itself.
Suppose that your entity has sub-entities:
|Parent Company |= ABC Inc.
|Subsidiaries |= D Corp.
| |= E Corp.
| |= F Corp.
The records for the subsidiaries will need to refer to the parent company. (This can be seen on the actual IDEN screen as the “Part Of” field.)
The parent record (parent company) will be set up with a null value for its own DEN_ID.
The dependant records (subsidiaries) will refer back to the parent record in the DEN_ID key.
|| ||ID||Entity||Foreign Key\\DEN_ID
|Parent| 1 |ABC Inc.| Null
|Dependant| 10 |D Corp| 1
| | 13 |E Corp| 1
| | 27 |F Corp| 1
!Exclusive Join
In the diagram below, the Contact table is connected to both the User and Identity tables. Highlighted in the diagram below are two circular symbols joined by a line. This indicates that there is an Exclusive Join with the Contact table
*** PICTURE ***
This exclusive join means that the contact table may be tied to either the User table or the Identity table, but not both. These tables
cannot have the same contact.
Occasionally you will see an exclusive join that isn’t connected to multiple tables. This simply means that for brevity sake, not all dependant tables are displayed on the chart
*** PICTURE ***
For example, Distribution can be joined to multiple tables, including the Assignment Detail, Position or Job tables. (Note however, that only the EASD tables is displayed here.)
!Diamond Symbol
On many lines there will be a diamond symbol.
This diamond means the parent table cannot be changed on the dependant record.
*** PICTURE ***
In the example above, the Alias record cannot be altered to point to a different Identity.
This page (revision-40) was last changed on 26-Nov-2021 10:22 by Karen ParrottTop