Part 2 - Key Fields

lecture lab details identity fields person identity – used to uniquely identify a person they are only used in primary entity tables there must be at least one of these but there can be more than one relationship identity (i e non person) – used to describe relationships from the primary entity tables of the real time customer profile to an associated supporting entity class (i e lookups) primary identity – can be either a person identity or relationship (non person) identity that is being used as a storage key and required for any schema being used by the real time customer profile for primary entity tables the identity also uniquely identifies a person when specified for xdm profile schemas and lookup schemas this field will determine whether a new record is created or an existing record is updated there must be exactly one of these required fields (xdm experience event only) id used by the real time customer profile in conjunction with the primary identity to create a unique storage key for the event required to prevent accidental duplication of event data within profile service timestamp – all events happen at a specific time and therefore every event requires a timestamp not required but highly encouraged event type – describes the high level behavior of the event data (i e purchase, reservation booked, etc ) general rules bridge table rule #2 in situations where a bridge table exists between a “ p ” or “ e ” parent (i e parent table) and a “ l ” table treat the bridge table as part of the parent table always validate that identities are unique to a single person at this stage to avoid rework during data ingestion for experience event schemas, the primary identity is what uniquely identifies that behavior to a single person for lookup tables, the primary key (pk) from the relational model will always be the non person primary identity for each table from the connection 5g warehouse erd and streaming erd that you have labeled as either a “p”, “e” or “l”, you will now perform the steps below to identify the primary identities, person identities, relationship identities and any required fields for the given schema classes refer to the diagram below during the labs as you label identities on schemas step 1 – label key fields in the xdm individual profile tables perform the below steps to identify the key fields within the customer account table identify the field that will be used as the primary identity and label it with a pi identify all other person identities and label them with an i identify any relationship identities and label them with a r step 2 – label key fields in the xdm experience event tables perform the same set of tasks you did in step #1 but now for the xdm experience event tables identify the field in each table that will be the primary identity and label it with a pi identify all other person identities in each table and label them with an i identify all relationship identities and label them with a r in addition to the labels above also label the following identify or create the unique event id for each xdm experience event table and label it with a id identify the event's timestamp for each table and label it with an t identify or create the event type for each table and label it with an et step 3 – label key fields in the lookup tables identify in each lookup table the field that will be primary identity and label it with a pi review