Hello Chiliyago,
This looks like a great case to do
some model optimization on. In other words, to represent the same bits
of information in another way in order to create something more
beneficial when mapped down. (Optimization is in one of the later
chapters of Halpin's book)
(seems I have yet to learn to post images here, so I will attempt to describe it by copying text from the verbalization window:)
ORM2 Verbalization
Booking Change is for initial creation.
ORM2 Verbalization
Booking Change is on Date.
Each Booking Change is on exactly one Date.
It is possible that more than one Booking Change is on the same Date.
ORM2 Verbalization
Booking Change is for Booking.
Each Booking Change is for exactly one Booking.
It is possible that more than one Booking Change is for the same Booking.
These three facts, including the newly introduced Unary, have an external uniqueness constraint over them affecting Booking Change. Copied is the verbalization shown when selecting the new Booking Change entity
ORM2 Verbalization
Booking Change is an entity type.
Reference Scheme: Booking Change has change id.
Reference Mode: change id.
Fact Types:
Booking Change is for initial creation.
Booking Change is on Date.
Booking Change is for Booking.
Booking Change has change id.
And the last fact, introduced by Ken
ORM2 Verbalization
Booking is for Seat.
Each Booking is for exactly one Seat.
For each Seat, at most one Booking is for that Seat.
When mapped, this will match what you said was desired; a single table, plus the new table introduced by Ken to show other information about a booking. It also makes even more clear the constraints in the earlier diagram which are probably incorrect. For example:
Only once a day may a person update some booking.
A person may create a booking only once per day.
A Booking can only be updated by a given person once.
A booking cannot be updated twice on the same date.
All a formula for frustrated customers!
If someone would diagram that and post thie picture, I'd appreciate it!
EDIT:
It seems I responded to the diagram without addressing the original question!
You may certainly introduce a new entity type named something to the tun of "Creation and Update Information." Attach four fact types to it, two to person two to date, and put the preferred identifier as the combination of these four facts. Now, everywhere in your model that references this new entity will map to show the four-part identifier. (created by, created on, updated by, updated on). You can also put in one single place in the model business rules such as:
'cannot be modified before creation'
'creation date is mandatory'
'updated date is optional'
'if an updated date is recorded, a person who updated is also recorded'