Zum Hauptinhalt springen
tsecurity.de LIVE
Echtzeit-Radar & Feeds
Alle RSS Feeds
👥 Community & Social
IT NachrichtenHow to use Xbox mode on your Windows PC(21.09.2026 um 00:30 Uhr)
Sichere ProgrammierungThe Indie Dev Visibility Playbook: From Zero Users to Your First 100(21.09.2026 um 00:08 Uhr)
Sichere ProgrammierungBase, Chat and Reasoning Models: How Are They Different?(21.09.2026 um 00:09 Uhr)
Sichere ProgrammierungHexfield Deck is for Kanban lovers and Markdown believers(21.09.2026 um 00:20 Uhr)
Sichere ProgrammierungPermissions and Authorisation: A Practical Playbook(21.09.2026 um 00:21 Uhr)
Linux Tipps & Hardeningfilet | Terminal File Manager(20.09.2026 um 21:03 Uhr)
IT NachrichtenHow to use Xbox mode on your Windows PC(21.09.2026 um 00:30 Uhr)
Sichere ProgrammierungThe Indie Dev Visibility Playbook: From Zero Users to Your First 100(21.09.2026 um 00:08 Uhr)
Sichere ProgrammierungBase, Chat and Reasoning Models: How Are They Different?(21.09.2026 um 00:09 Uhr)
Sichere ProgrammierungHexfield Deck is for Kanban lovers and Markdown believers(21.09.2026 um 00:20 Uhr)
Sichere ProgrammierungPermissions and Authorisation: A Practical Playbook(21.09.2026 um 00:21 Uhr)
Linux Tipps & Hardeningfilet | Terminal File Manager(20.09.2026 um 21:03 Uhr)
Intelligence View
⚡ tsecurity.de Intelligence

SFMC Data Model and Cardinality: Wire DEs Together Without Regret

Reagiere als Erste:r — dein Feedback zählt!

Teams new to SFMC create Data Extensions as requirements arrive. Today's send needs a list, tomorrow's loyalty feature needs a separate DE, next week's CRM sync adds three more. Three months in: 20 DEs, nothing can be joined, no cross-data segmentation works, no audit trail.

The fix is 30 minutes on a whiteboard before the first DE exists. Two concepts carry it: Database of Record and Cardinality.

Database of Record (DBOR)

The DBOR is the single source of truth for subscriber identity. Every other data source points at it.

Discovery question for the client:

One answer. If the client says "all of them," help them decide - usually by picking the system that currently drives business operations (order fulfillment, customer service queries).

The DBOR defines the Subscriber Key. All SFMC DEs that hold subscriber data use an ID that maps back to the DBOR.

Subscriber Key strategy

Once DBOR is decided, the Subscriber Key follows:

  • If DBOR is Salesforce CRM, use the CRM ContactID as Subscriber Key.
  • If DBOR is e-commerce, use the e-commerce customer ID.
  • If DBOR is a data warehouse, use whatever stable ID that warehouse assigns (often a UUID).

The Subscriber Key must be stable - never changes over a customer's lifetime. Email addresses change; Shopify IDs can reset on a store migration; a purpose-built CustomerID is safest.

Document the Subscriber Key rule in the data model doc. When new data sources arrive later, they get plumbed through the same Subscriber Key.

The hub-and-spoke model we use most

Rather than one giant DE with every column, split by function:

Master holds the subscriber-facing attributes. Spokes hold the detail. Joins happen via AMPscript Lookup or Automation Studio SQL, not by duplicating columns.

Cardinality in Contact Builder

When you link DEs in Contact Builder for cross-DE segmentation, SFMC asks about cardinality - the relationship between two DEs:

CardinalityMeaningExample1:1One row in A relates to one row in BCustomer -> primary Address (each customer has one primary)1:ManyOne row in A relates to many rows in BCustomer -> Orders (one customer, many orders)Many:ManyMany rows in A relate to many in BCustomer -> Product (via Order_Items - each customer can buy many products, each product bought by many)

Getting cardinality wrong breaks segmentation:

  • Declaring 1:1 when it's actually 1:Many means SFMC ignores all but the first matched row.
  • Declaring 1:Many when it's actually 1:1 is harmless but lets you accidentally pick multiple rows.
  • Many:Many relationships require a junction DE (Order_Items) to resolve properly.

The data model doc we produce

Before touching SFMC for a new engagement, we write a one-page data model:

  1. DBOR - which system is the source of truth.
  2. Subscriber Key - exact field name, data type, where it originates.
  3. Master DE - list of fields, types, nullability, source system.
  4. Spoke DEs - name, purpose, cardinality to Master, source system.
  5. Lookup DEs - name, purpose, primary key.
  6. Contact Builder relationships - which DEs get linked, cardinality.

Review with the client. Once signed off, building in SFMC follows the doc rather than the other way around.

Why this matters on inherited engagements

When picking up a poorly-modeled SFMC account, the symptoms are predictable:

  • Segmentation that should be possible isn't.
  • Same person appears multiple times in audiences.
  • Cross-DE reports have to be built with SQL outside SFMC.
  • Contact Builder has 15 linked DEs and nobody knows the cardinalities.

The remediation is the same whether you're starting fresh or remodeling: define DBOR, fix Subscriber Key, introduce a Master DE, migrate downstream.

Takeaway

Data modeling doesn't feel productive because you're not building anything yet. On SFMC engagements it's the most leveraged hour of the whole project. Write the data model doc, get client sign-off, then build. The alternative is the 20-DE sprawl that eats your Q2.

Modeling an SFMC data architecture? Our Salesforce team designs data models, Subscriber Key strategies, and Contact Builder relationships on production engagements. Get in touch ->

See our full platform services for the stack we cover.

Ähnliche Beiträge
🔍 Verwandte News

Auch interessante Nachrichten SFMC Data Model and Cardinality: Wire DEs Together Without Regret

Thematisch verwandte Begriffe: SFMC, Data, Model, Cardinality · 6 Treffer

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Zum Aktualisieren ziehen
ZERO-DAY CVE-2026-94084 | Suricata before 8.0.7 has an Http2ThreadMultiBuf use-after-free when a t…
Advisory →
TTS Reader • tsecurity.de Voice
tsecurity.de Icon
tsecurity.de App
Offline-Lesen, Eilmeldungen & 0ms Ladezeit

Installiere tsecurity.de direkt auf deinen Home-Bildschirm für das ultimative Vollbild-Magazinerlebnis ohne Browser-Leisten.

Nächster Beitrag
Themen-Radar & Intelligence Matrix
Echtzeit-Taxonomie nach Angriffsvektoren & Plattformen

tsecurity.de Live Threat Radar

🔴 LIVE RADAR
MONITORING
AKTIV
CVE-DATENBANK
LIVE
🔍
Community Radar & Live Chat
Sentinel Bot online • Live-Stream
Dein Cluster: Security Explorer
Match:
lädt…
Verbindung zum Community-Stream wird aufgebaut...
Bearbeitungsmodus — Senden überschreibt deine Nachricht
Community-Puls — was gerade passiert
lädt…
Aktivitäten deiner Analysten
lädt…
Neues Thema oder Eilmeldung einreichen

Reiche interessante Links, Zero-Days oder Debatten ein. Die Community entscheidet per Upvote über die Veröffentlichung.

Heiß diskutierte Einreichungen
🔖 Gespeicherte Artikel
📂 Keine gespeicherten Artikel vorhanden.
Zurück Ziehen Vor
Links: vorheriger Artikel Rechts: nächster Artikel unten: schließen
News NIS-2 Frühwarnung Tier-1 Intel ⏱️ 3 Min vor 10 Min
Artikeldaten werden geladen...

Zurück: vorheriger Vor: nächster
↗ Original-Quelle
Social Reaktionen Deine Reaktion zählt
Einstufung & Relevanz-Poll 0 Stimmen
In sozialen Netzwerken teilen 1-Klick