I’m implementing a system (one that I have been working on all year) this weekend. As such, the hours are getting long and all I have time for is a shorter entry...

Surrogate keys can be implemented in ORM by merely using a surrogate object and fact. For example, you could introduce the fact "Person is identified by PersonID()" and you have implemented a surrogate key for Person. Remember that you have to make each role unique as each Person can have only one PersonID and each PersonID can be for only one Person. You also have to annotate the PersonID uniqueness constraint with a P which means it is the primary reference mode for Person.

If the object type has an internal reference mode – say Person(ssn) – you need to externalize the reference mode as a distinct fact: "Person is also identified by SSN()". Then, you can either implement the surrogate identifier as an internal reference mode – Person(PersonID) – or like above as an explicit fact. When externalizing the existing reference mode, don’t forget to make the both roles unique as above.

If the object type is co-referenced, then you need to make the co-referenced primary reference mode into a regular external uniqueness constraint. Using an example from an earlier entry, the facts "Course is part of Enrollment" and "Student is part of Enrollment" have an external uniqueness constraint on the Course and Student roles making that combination unique for all Enrollments. Further, that constraint is annotated with a P indicating that it is the primary reference mode for an Enrollment. If you want to implement a surrogate key for Enrollment, merely demote the P to be a regular uniqueness constraint (i.e. annotated as U) and then add the surrogate reference mode as above.

Using the nested case from that same example, We would remove the P spanning the Course and Student roles of the nested predicate composing the Enrollment object type and then add the fact Enrollment is identified by EnrollmentID(), with each role being (individually) unique and the EnrollmentID() role being the primary reference mode (i.e. annotated with a P).

[Notice how adding surrogate keys makes the ternary pattern for this set of facts less attractive.]

Hopefully, you have noticed a pattern. We always start with an existing reference mode and then modify the model to implement the surrogate. The combination of Student and Course must be unique in our Universe of Discourse regardless of whether or not we choose to implement Enrollment’s primary key as an identity column or GUID. Ditto for SSN. Thus...

Rule: Surrogate keys are fine as long as you have a real-world reference mode – implemented as a uniqueness constraint – for every entity object type.

If you get in the habit of always demoting a reference mode to be a mere uniqueness constraint you’ll have less data errors in your resulting schema.