Customer 360 Enterprise Data Platform — Denodo on Azure  ·  View 16 of 39  ·  Data

The Customer 360 Logical Model

The entities a consumer sees, the one key they all join on, and where the source keys survive.

Editable source SVG draw.io All views
source_customer_xref xref_id PK ecid FK -> enterprise_customer source_system source_customer_id match_score valid_from customer_contact contact_id PK ecid FK email PII phone PII postal_address PII is_primary customer_account account_id PK ecid FK product_code opened_on account_status customer_order order_id PK account_id FK order_date net_amount currency customer_activity activity_id PK ecid FK event_time event_type channel enterprise_customer ecid PK primary_name customer_status segment_code authoritative_source resolved_at customer_case case_id PK ecid FK opened_at sla_due_at case_state channel customer_invoice invoice_id PK order_id FK due_date paid_flag outstanding dq_exception exception_id PK ecid FK rule_code severity detected_at customer_value ecid PK, FK lifetime_value churn_score scored_on customer_campaign campaign_ref PK ecid FK sent_at responded_flag channel 1 : N 1 : N 1 : N 1 : N 1 : N 1 : N 1 : N 1 : 1 1 : N 1 : N Customer 360 — The Logical Data Model Consumers See The enterprise id is the only join key above layer 2. Source keys survive in the crosswalk so any figure can be traced back to the system that produced it. v 1.0 · owner Data & AI Global Practice · date 2026-09

Decisions

  • The enterprise id is the only join key above layer 2. No business view exposes a source key, and no consumer has ever had a reason to ask for one.
  • Source keys survive in the crosswalk rather than being discarded, so any figure on any report can be traced back to the row in the system that produced it.
  • Quality exceptions are an entity, not a column. A record with a blocking defect is held out of the 360 and its reason is queryable.

Classification

  • Personal data is concentrated in customer_contact by design, so masking policy applies to one entity rather than being scattered across the model.
  • customer_value holds derived scores under a separate restriction: approved purposes only, because a churn score is not the same kind of secret as an email address.

Deliberate omissions

  • Consent and preference entities exist and are omitted here for legibility; they follow the same pattern as customer_contact and are shown in the masking classes on view 37.
  • Only the keys and the columns needed to follow the joins are listed.