Notice how there are two foreign keys in the RE_ACTION table: email_action_id and datamap_action_id. One of these must always be NULL. I didn't like this approach because the structure of the table would change if and when we invent new types of actions.
The major difference here is that the RE_ACTION table becomes merely the source of available action_id key values, which are used as foreign keys by the other two Action tables. This reverses the relationship! Before these tables embedded their primary key values in the RE_ACTION table.
Notice also that we've added a new table, the RE_EXPR_ACTION table, which uses a composite key to guarantee only one action of each type per Expression. Then the RE_ACTION table donates its primary key as a foreign key into this table, and that makes the relationship between Actions and Expressions. In the old design, the RE_ACTION table was trying to be a link table between Actions and Expressions and was also a "lookup" table for the specific action type.
Split RE_ACTION table into two tables with distinct purposes, and reversed the direction of the foreign key relationships from the general Action_IDs and the specific Action_IDs. Notice how there are two foreign keys in the RE_ACTION table: email_action_id and datamap_action_id. One of these must always be NULL. I didn't like this approach because the structure of the table would change if and when we invent new types of actions.